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

[Nicholas Allen]

I've started converting our code to use XCB ;-) It seems that this is
the future for x client libraries and I really like how the API is so
low level and asynchronous.

I should be able to complete the conversion in the next day or 2 and
then will be able to check if the bug is fixed. XCB looks really great!

In AWT they post events from the native event loop into a Java event
queue and a separate Java thread then processes that queue. When you do
SwingUtilities.invokeLater it just puts a runnable into the Java event
queue and does not need to do anything with the native event dispatch
thread.

This approach is also the approach we use in our windowing system
abstraction.

Cheers,

Nick

Jamey Sharp wrote:
> 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
>