XInitThreads in library constructor breaks Motif!

[Carsten Haitzler]

On Mon, 31 Oct 2022 20:18:02 +0800 Po Lu <luangruo at yahoo.com> said:

> Carsten Haitzler <raster at rasterman.com> writes:
> 
> > 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.
> 
> Which Xlib breaks, by initializing threads.

no it doesn't. the contract is simply to not use motif from multiple threads.
it has nothing to do with xlib itself becoming threadsafe. i think the PR/MR
for xlib has all the details you want listed in it.

> > 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 :)
> 
> XCB afaik doesn't start multiple threads itself, so I don't see the
> problem at all.

it has nothing to do with it. xcb is an artefact of how xlib is implemented
today - it absolutely is not part of the spec or design or requirements.

> If there is really a big problem with clients using XCB, then why not
> call XInitThreads in XGetXCBConnection instead?

has nothing to do with it. having xlib just be threadsafe always when it is as
easy as xinitthreads being the default anyway is nice. it doesn't violate the
xlib contract with users of it if they are correctly implemented. as some have
not been - the proposed patch up in the thread works around that. another
possible solution would be a recursive lock.


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