From 6310475e23eac6917db54f1425e20d8434bee679 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rami=20Ylim=C3=A4ki?= Date: Wed, 13 Oct 2010 17:48:13 +0300 Subject: Prevent reply waiters from being blocked. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It's possible to call xcb_wait_for_reply more than once for a single request. In this case we are nice and let reply waiters continue so that they can notice that the reply is not available anymore. Otherwise an event waiter could just signal the reply waiter that got its reply to continue but leave a waiter for an earlier reply blocked. Below is an example sequence for reproducing this problem. thread #1 (XNextEvent) - waits for events thread #2 (XSync) - executes request #2 - waits for reply #2 thread #1 - reads reply #2 - signals waiter of reply #2 to continue - waits for events thread #2 - handles reply #2 thread #3 (XCloseDisplay) - executes request #3 - waits for reply #2 thread #1 - reads reply #3 - nobody is waiting for reply #3 so don't signal - wait for events Of course it may be questionable to wait for a reply twice, but XCB should be smart enough to let clients continue if they choose to do so. Signed-off-by: Rami Ylimäki Signed-off-by: Jamey Sharp --- src/xcb_in.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/xcb_in.c') diff --git a/src/xcb_in.c b/src/xcb_in.c index a084b3f..7d34429 100644 --- a/src/xcb_in.c +++ b/src/xcb_in.c @@ -211,9 +211,9 @@ static int read_packet(xcb_connection_t *c) XCB_SEQUENCE_COMPARE(reader->request, <=, c->in.request_read); reader = reader->next) { + pthread_cond_signal(reader->data); if(reader->request == c->in.request_read) { - pthread_cond_signal(reader->data); break; } } -- cgit v1.2.3