[Xcb] libxcb/libX11 deadlocking and asserting in multi-threaded use

[Jamey Sharp]

On Sat, Mar 20, 2010 at 4:35 AM, Nicholas Allen
<nick.allen at onlinehome.de> wrote:
>> By the way, you can always work around Xlib threading issues by using a
>> mutex of your own to ensure that you never call Xlib from more than one
>> thread at once. I'm told this was a common strategy even before
>> Xlib/XCB.
>
> How would I call XNextEvent in this case? XNextEvent will block while
> still holding my mutex so all other threads will also block until an
> event arrives.

True. I don't know how other people do it. There's the example of AWT,
which requires all GUI operations to be done on the event thread, but
somehow calls like SwingUtilities.invokeLater can wake up that thread
while it's waiting for an event. Maybe they're using select/poll on
the X connection's file descriptor rather than blocking in XNextEvent?

Another hybrid option: port all of your event handling to XCB, but
still use Xlib for other purposes. See XSetEventQueueOwner. Then you'd
make Xlib calls from one thread at a time, but XCB calls including
event handling from any thread. If there are bugs in XCB's thread
support (and I'm pretty confident that code is correct) they should be
much easier to track down and fix. Note that migrating event handling
to XCB is all-or-nothing: if you do this, XNextEvent and friends will
never return any events.

I'm still not trying to weasel out of fixing the actual bug, but we've
put a lot of work into these migration plans and I can't help
encouraging people to use them. ;-)

Jamey