Comment 45 for bug 86103

(In reply to comment #11)
> 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.

'Extensions' aren't thread-aware. They're just a bit of wire protocol and some code on the server which processes client requests. The server obviously has no way to know if a client's using threads, and doesn't care.

> 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?

The solution is brutally simple: _share_ shared libraries. You're attempting to solve a distributor's problem as an ISV, and it's not working. If you want to distribute X client libraries, distribute Xlib and all your extension libraries. Don't just do half of it and be surprised when it doesn't work.

> Why _should_ the client-side library for the extension care whether Xlib is
> thread-capable?

Because the entire Xlib stack sucks, which is why we're trying our hardest to get rid of Xlib?

> 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?

Because building with XTHREADS or not determines how the ABI is managed. I don't know anyone who builds without XTHREADS support these days. If your concern is about old systems, then, well, they're immutable, and we can't exactly just disable threads for all systems.

So, it comes down to this: if you really want to support ancient systems, distribute Xlib and all your extension libraries. If you don't, then build your libraries with XTHREADS support, as everyone builds Xlib with XTHREADS. Everyone wins.

We can't fix Xlib's API/ABI (both are set in stone for obvious reasons), nor can we do anything about the inadequacies of various distributions or systems. If you want to patch these up yourself, please feel free, but don't be surprised if it all falls apart.

Our position is that this bug is NOTOURBUG. If you would like to fix this once and for all, please investigate XCB. Thanks.