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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
