XInitThreads in library constructor breaks Motif!

Carsten Haitzler raster at rasterman.com
Mon Oct 31 07:55:54 UTC 2022


On Mon, 31 Oct 2022 08:11:09 +0800 Po Lu <Luangruo at yahoo.com> said:

> 
> 
> On October 31, 2022 7:08:50 AM GMT+08:00, Alan Coopersmith
> <alan.coopersmith at oracle.com> wrote:
> >On 10/29/22 19:00, Po Lu wrote:
> >> Motif assumes that you can call functions that lock the display inside
> >> XCheckIfEvent as it never calls XInitThreads itself.  It also never uses
> >> threads.
> >
> >It was never up to Motif to decide whether or not to call XInitThreads()
> >- that decision was up to the applications, and if Motif assumed no
> >application would ever do that, it was buggy and incompatible with such
> >applications.
> 
> Okay, so what about the countless Motif *applications* that don't use
> threads?  Motif is not a thread-safe library, and is documented as such, so
> Motif applications (mine included) deliberately do not call XInitThreads.

using motif and using xlib are different things. you are still free to use xlib
separately to motif and thus use it from multiple threads... as long as you use
motif and only motif from a single thread, you agree to the non-threadsafe
contract.

> >https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/150 is
> >a proposed solution to the problem, but has not generated any interest
> >in testing it or moving it forward, suggesting either everyone is
> >building with the --disable-thread-safety-constructor option or is
> >using correctly written software that does not make such assumptions.
> 
> Or most people are on Xlib 1.7.x.  Anyway, the documentation for X*IfEvent
> says it is okay to call functions that take the display lock inside the
> predicate given that it does not change the event queue.  I have written such
> software, and clearly the Open Group has too, along with XFCE, etc.

the solution to this is... use a recursive lock in xlib or change the
locking around xcheckifevent and friends to unlock when going into the
callback (which is the current proposed solution in gitlab). the point of
locking is to keep xlib working with multiple threads as it would with a single
one and this would honor that goal :)

> Besides, how to move it forward? If it works, wouldn't the obvious solution
> be to install the change? If all that is needed is for someone to try it out,
> I'd be happy to do it, but I'm pretty sure the better solution is just to
> remove the call to XInitThreads in the first place.
> 
> So please don't make arbitrary changes to documented behavior!! There are
> people who pay for Motif, and such things did not happen when both Motif and
> Xlib were being developed under the auspices of the Open Group.
> 
> Thanks.
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com



More information about the xorg-devel mailing list