[Xcb] Multithreading bug in Xlib/XCB

Yaakov Kaston ykaston at gmail.com
Sun Apr 12 03:30:33 PDT 2009


I’ve reported a bug, long ago, regarding synchronous X Library functions. (

After investigating it a little further, it looks like a bug in the
extension code that was added to the X library to use XCB.

The _XReply function (xcb_io.c) maintains a replies list
(dpy->xcb->pending_requests). So when a new synchronous request is queued it
is added to this list and the function is waiting for a reply in
xcb_wait_for_reply. When an error returns, it is matched against the
pending_requests and all is well.

That is until another thread calls an asynchronous function (like
XNextEvent). The wait_or_poll_for_event  function (xcb_io.c, called), called
from process_responses, is calling xcb_wait_for_event (xsb_in.c), this in
turn reads all events and errors. This function is part of XCB is not aware
of the pending request  list maintained by the X library. When read_packet
(xcb_in.c) is called it checks against the internal list
(c->in.pending_replies) and never finds any pending requests, thus the error
is being appended to the event queue, and an IO error is issued by _XReply
in the first thread.

This makes the XCB based X library unusable in multithreaded GUI
applications. Some large customers that want to utilize Fedora Core 8 or
above or SLES11 find this very annoying.

There are two possible ways to solve this. One is to remove pending_requests
list from the X library and handle this list directly in XCB. The other way
is to check errors returned by XCB against this list.

Who is familiar with this code enough to explain which way would not harm
the current design of the Xlib/XCB integration?


Yaakov Kaston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xcb/attachments/20090412/fb0dbd4e/attachment.html 

More information about the Xcb mailing list