diff options
author | Uli Schlachter <psychon@znc.in> | 2015-06-12 15:13:05 +0200 |
---|---|---|
committer | Uli Schlachter <psychon@znc.in> | 2015-06-25 20:38:48 +0200 |
commit | 5b40681c887192307f3ae147d2158870aa79c05f (patch) | |
tree | 6daf8beba24a957c731fb51a418caa48f1172fec /src/Makefile.am | |
parent | f85661c3bca97faa72431df92a3867be39a74e23 (diff) |
Fix a thread hang with xcb_wait_for_special_event()
Consider the following:
- Two threads are calling xcb_wait_for_special_event() and xcb_wait_for_reply()
concurrently.
- The thread doing xcb_wait_for_reply() wins the race and poll()s the socket for
readability.
- The other thread will be put to sleep on the special_event_cond of the special
event (this is done in _xcb_conn_wait() via the argument
xcb_wait_for_special_event() gives it).
- The first thread gets its reply, but does not yet receive any special event.
In this case, the first thread will return to its caller. On its way out, it
will call _xcb_in_wake_up_next_reader(), but that function cannot wake up
anything since so far it did not handle xcb_wait_for_special_event().
Thus, the first thread stays blocked on the condition variable and no thread
tries to read from the socket.
A test case demonstrating this problem is available at the bug report.
Fix this similar to how we handle this with xcb_wait_for_reply():
The function wait_for_reply() adds an entry into a linked list of threads that
wait for a reply. Via this list, _xcb_in_wake_up_next_reader() can wake up this
thread so that it can call _xcb_conn_wait() again and then poll()s the socket.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252
Signed-off-by: Uli Schlachter <psychon@znc.in>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Diffstat (limited to 'src/Makefile.am')
0 files changed, 0 insertions, 0 deletions