<div dir="ltr">Hi, I’ve reported a bug, long ago, regarding synchronous X Library functions. (<a href="http://bugs.freedesktop.org/show_bug.cgi?id=17010">http://bugs.freedesktop.org/show_bug.cgi?id=17010</a>). 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<span dir="RTL" style="font-family:"Arial","sans-serif";mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin;mso-hansi-font-family:Calibri;mso-hansi-theme-font: minor-latin;mso-bidi-font-family:Arial;mso-bidi-theme-font:minor-bidi"> 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? Thanks, Yaakov Kaston </div>