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

[Jamey Sharp]

On Fri, Mar 19, 2010 at 09:24:44PM +0100, Nicholas Allen wrote:
> Jamey Sharp wrote:
> > That assertion is a symptom of a fairly broad range of problems. All it
> > means is that a response arrived for a request that hasn't been sent
> > yet.
>
> Sounds impossible ;-)

Not only that, it's *inconceivable*! ;-)

Yeah, that's why it's an assert. :-)

> > In the case of that bug report and its many duplicates, it sounds to
> > me like the application opens an X connection, fork()s, and then
> > accesses the connection from both processes. That's never going to
> > work.
>
> We don't fork. Everything is done with threads within one process.

Yeah, I figured. So you see that you have a different bug that just
happens to have the same symptom sometimes.

> > I'd be even happier, of course, if you ported your Java implementation
> > to use XCB directly. ;-)
>
> 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?

> 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. :-)

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20100319/ab63be89/attachment.pgp>