[PATCH] [libX11/XCB] Thread starves in _XReply() while anohter thread executes _XReadEvents()

[Martin Wilck]

Hello,

I encounter the following situation on my system reproduceably when I
run the synergy KVM switching software (server side).

Thread A is stuck in this call path:

XSync()
   _XReply()
	// line 625 ff: wait for event_waiter to process first event
        while(dpy->xcb->event_waiter)
        { /* need braces around ConditionWait */
             ConditionWait(dpy, dpy->xcb->event_notify);
        }

I observe that this thread never leaves this while loop any more.

Thread B executes:

XIfEvent()
   _XReadEvents()

Until the event it's waiting for arrives, XIfEvent() calls
_XReadEvents() in a loop with the display lock held. _XReadEvents() only
releases the lock after setting dpy->xcb->event_waiter. Only after
re-acquiring the lock, it clears event_waiter and sends a broadcast for
the condition variable dpy->xcb->event_notify.

In this situation, thread A is effectively blocked: ConditionWait()
receives the broadcast, but before it can acquire the display lock and
return, _XReadEvents() will have set event_waiter once more, so it needs
to wait again.

This goes on forever unless the event XIfEvent() is waiting for arrives.
In some situations, this seems to take a forever too, I'm not sure why
(maybe we are looking at a deadlock situation here in the sense that the
expected condition can't happen unless thread A gets a chance to run).

I am attaching a tentative patch that I've come up with. Please review
it. The rationale is to yield to a request waiter after grabbing one
event. I am currently testing it on my system (too early to come to a
conclusion though, at least it doesn't seem to have caused a regression
so far).

CC'ing Jamey who seems to be the expert on XCB locking matters.

The thread
https://groups.google.com/forum/#!topic/synergy-users/4O_Xod9HV-A
suggests that other people are seeing the same problem. It also suggests
that this only occurs wiht recent versions of synergy. However, IMO the
above analysis rather indicates a general XCB problem. Please comment.

Regards
Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: _XReply-locked-by-_XReadEvents.patch
Type: text/x-patch
Size: 709 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160720/01743eac/attachment.bin>