diff options
author | Rami Ylimäki <rami.ylimaki@vincit.fi> | 2010-10-13 17:48:13 +0300 |
---|---|---|
committer | Jamey Sharp <jamey@minilop.net> | 2011-03-14 17:19:14 -0700 |
commit | 6310475e23eac6917db54f1425e20d8434bee679 (patch) | |
tree | 3d5aae1134f34284322056f6f0c47ab2acf5b675 /src/xcb_in.c | |
parent | 29ab5aeb9b1b1daf7f0659b134a4cfe9f42ca71a (diff) |
Prevent reply waiters from being blocked.
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 <rami.ylimaki@vincit.fi>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Diffstat (limited to 'src/xcb_in.c')
-rw-r--r-- | src/xcb_in.c | 2 |
1 files changed, 1 insertions, 1 deletions
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; } } |