[Xcb-commit] src

[Jamey Sharp]

 src/xcb_in.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 6310475e23eac6917db54f1425e20d8434bee679
Author: Rami Ylimäki <rami.ylimaki at vincit.fi>
Date:   Wed Oct 13 17:48:13 2010 +0300

    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 at vincit.fi>
    Signed-off-by: Jamey Sharp <jamey at minilop.net>

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;
             }
 	}