[PATCH libX11] config: Add an option to initialize threads by default.

[Rami Ylimäki]

On 01/31/2011 09:11 PM, Alan Coopersmith wrote:
> On 01/31/11 02:46 AM, Rami Ylimäki wrote:
>> It's sometimes impossible to know in advance whether an X client is
>> using Xlib from multiple threads or not. For example, there could be
>> some generic X client that acts as a plugin container. Plugins could
>> be loaded to the container at runtime, but the container doesn't know
>> whether the plugins are using Xlib from a separate thread or not.
> I don't know if it's a better answer, but an alternate solution we've
> been carrying around in Solaris libX11 since long before I got here is
> to allow XInitThreads() to be called by other plugins/libraries even after
> the X connection is up and running.    I've not checked how well it works
> in the current world where half of XlibInt.c was ripped out and replaced
> by xcb calls, but the code is available if someone wants to look at it.
>
> Original version:
> http://people.freedesktop.org/~alanc/thread-fixes/
>
> Current version:
> http://src.opensolaris.org/source/xref/x-cons/xnv-clone/open-src/lib/libX11/1234757.patch
> http://src.opensolaris.org/source/xref/x-cons/xnv-clone/open-src/lib/libX11/4010755.patch
>

Thanks for the links.

The problem that your patches fix is very similar to what I have 
encountered and which the current semantics of XInitThreads are 
completely insufficient to solve. Libraries might find it convenient to 
use threads and/or Xlib to implement some functionality. However, an 
application linking to those libraries has no way of knowing that 
XInitThreads should be called, because the application doesn't 
necessarily even know that some of its libraries are using Xlib.

Therefore it's tempting to change the semantics as you have done. 
However, this is still insufficient to solve the problem in general 
case. It should be possible to guard against multiple simultaneous 
XInitThreads calls and also against XInitThreads calls happening during 
error handler and request/event processing. To make it work, you'd still 
need to have some locks initialized before the first call to 
XInitThreads is done, which pretty much reduces to enabling locking by 
default.

I discussed this with Erkki and we came up with the following solution:

   - add configuration option to initialize locking functions by default
   - the initial locking functions call try_lock() instead of lock() and 
assert on failure
   - the locking functions are initialized as before in first call to 
XInitThreads

So in practice we would be detecting incorrect usage of Xlib from 
multiple threads reliably until XInitThreads is called. This solution 
would at least give the application developer immediate feedback that 
Xlib is used incorrectly so that he wouldn't have to file a bug about a 
random crash in Xlib. What do you think?

-- Rami