-
Jamey Sharp authored
This bug appears as a hang in applications that wait for replies from multiple threads, where one such thread has taken a user lock using XLockDisplay. Prior to this fix, the code could deadlock in this way: If thread 1 goes to sleep waiting for a reply, and then thread 2 takes a user lock and waits for a reply, then thread 2 will wait for thread 1 to process its reply (because responses must be processed in order), but thread 1 will wait for thread 2 to drop its user lock. Fixed by making thread 1 not wait for thread 2 to drop its user lock. This makes the semantics of user locks hard to define, but they were already hard to define. The new behavior appears to be consistent with the way Xlib worked historically, anyway. Fixes: http://lists.freedesktop.org/archives/xcb/2011-March/006802.html There was a similar potential for deadlock in _XReadEvents, fixed the same way, with the same caveats about user-lock semantics. Signed-off-by: Jamey Sharp <jamey@minilop.net>
fd85aca7