summaryrefslogtreecommitdiff
path: root/xcb-res.pc.in
diff options
context:
space:
mode:
authorUli Schlachter <psychon@znc.in>2015-06-12 15:13:05 +0200
committerUli Schlachter <psychon@znc.in>2015-09-05 14:56:51 +0200
commit00903d4d6a32d498bd5d1eb8b7b733b133bc9692 (patch)
tree20e88e51357f4609b644bac092559444266166c8 /xcb-res.pc.in
parenta31c295870f2812cb2ce4cff351e2c0a3b144661 (diff)
Fix a thread hang with xcb_wait_for_special_event()1.11
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 'xcb-res.pc.in')
0 files changed, 0 insertions, 0 deletions