Comment 44 for bug 86103

(In reply to comment #10)
> (In reply to comment #9)
> > This does appear to be a bug in XCB, in that there is no reason why a
> > single-threaded binary that makes use of an X extension shouldn't run against
> > both XTHREAD and non-XTHREAD copies of Xlib without difficulty.
> That doesn't describe the problem here. An arbitrary single-threaded binary
> using an X extension can work with either an XTHREADS Xlib and XTHREADS
> extension or a no-XTHREADS Xlib and a no-XTHREADS extension. However, that
> does not mean it will work with a no-XTHREADS extension and an XTHREADS Xlib or
> vice-versa. Nothing ever said that would work, either before or after XCB.

The extension is part of the X server - whether or not it's thread-aware depends upon whether the server (or module) was build to be, which is entirely independent of whether an individual client's Xlib implementation is thread-aware.

The situation I'm describing is an application which can use a particular X extension if present, and which has the code to do that built-in - it's not loading a library from the host system in order to access the extension, it's doing it itself via the installed Xlib. Even if it were to use a dynamic library to access the extension, how is the library-builder to know whether the particular Xlib installed on that host system is thread-capable or not?

Why _should_ the client-side library for the extension care whether Xlib is thread-capable? If the client-side library is built to be thread-capable but Xlib is not then XInitThreads() will fail at application startup and the app will be single-threaded, so Xlib should be happy & the locking operations a thread-capable version provides are no-ops. If the client-side library is not thread-capable and it's used by an application that never calls XinitThreads() then why shouldn't a thread-capable Xlib support that?