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

[Nicholas Allen]

>> That's something I'd be willing to do. The thing is that we use cairo as
>> a graphics library
>>     
>
> That's great! Is this a Java2D implementation, or something more
> specialized?
>   
It's something more specialized: we're writing a cross platform
windowing system abstraction layer for our application instead of using
AWT/Swing. We need more control over the behavior of events than what
AWT provides. We are also considering to open source this abstraction
layer in the future when it is more complete.
>   
>> and I only found documentation for using cairo with xlib and not xcb
>> directly. Do you know if it's possible to use cairo with xcb?
>>     
>
> Yup! I wrote the original cairo virtualized backend patch because I
> wanted it to have an XCB backend, so that's one of the oldest backends
> cairo has.
>
> It still isn't officially supported, but Chris Wilson has been hard at
> work on that recently. The 1.9.6 snapshot appears to include a lot of
> his effort in this area. The most relevant commit message says:
>
>     Still an experimental backend, it's now a little too late to stabilise
>     for 1.10, but this should represent a major step forward in its feature
>     set and an attempt to catch up with all the bug fixes that have been
>     performed on xlib. Notably not tested yet (and expected to be broken)
>     are mixed-endian connections and low bitdepth servers (the dithering
>     support has not been copied over for instance). However, it seems robust
>     enough for daily use...
>     
>     Of particular note in this update is that the xcb surface is now capable
>     of subverting the xlib surface through the ./configure --enable-xlib-xcb
>     option. This replaces the xlib surface with a proxy that forwards all
>     operations to an equivalent xcb surface whilst preserving the cairo-xlib
>     API that is required for compatibility with the existing applications,
>     for instance GTK+ and Mozilla. Also you can experiment with enabling a
>     DRM bypass, though you need to be extremely foolhardy to do so.
>
> Meanwhile, of course, compiling Xlib with XCB support isn't supposed to
> break applications, so if we can track down the bug you're seeing,
> that'd be great. :-)
>   
Thanks for the info. That sounds really promising - I'll try and get
into the XCB api and port our windowing system over. In the meantime I'm
still struggling to find a way to easily reproduce the bug.

Cheers,

Nick