XInitThreads in library constructor breaks Motif!

[Carsten Haitzler]

On Tue, 01 Nov 2022 18:32:38 +0800 Po Lu <luangruo at yahoo.com> said:

> Carsten Haitzler <raster at rasterman.com> writes:
> 
> > Sorry - but no. Motif being non-threadsafe and Xlib being threadsafe or not
> > are different matters. A higher level lib that is not threadsafe makes use
> > of a lower level one (xlib) and the latter can be threadsafe if desired.
> 
> Being thread-safe is one thing.  Deadlocking clients is another.  If
> Xlib calls XInitThreads in a library constructor without consequences to
> programs 

i think we have covered that pointing to the mr/pr.

> > They man xinitthreads() then use motif from a single thread. Xlib can
> > be used then from multiple threads (e.g. one motif handled window and
> > another xlib handled window which is drawn to in another thread but
> > the same xlib display and connect below it all - as long as you are
> > not consuming events from both threads).
> 
> Then any program doing that cannot use Motif.  How simple is that?
> 
> > ??? Did you not read what I wrote? You are saying I said the opposite of
> > what I clearly wrote - xcb has nothing to do with discussing xinitthreads
> > being validly enabled or not by default. this really has nothing to do with
> > xcb. xlib being built on xcb is just a happenstance of how xlib is built
> > today and modern code can actually mix and match xcb and xlib, but it's not
> > part of the core issue.
> 
> Evidently, the author of the change in question disagrees.  Motif is not
> safe to use after calling XInitThreads, and the Motif applications on my
> desktop don't do that.  Yet, without doing so, they were frozen, as I
> found out trying to make a calendar appointment.

they are making that argument. i am not. xinitthreads being automatically
called/enabled and xcb are separate things. we can have this discussion
entirely devoid of xcb existing. should threadsafe xlib be a default anyway?
why not? the mr in this thread addresses the deadlock but x11r6 breaks things
anyway so there is certainly room for x11r6 breaking vs x11r5. it certainly
broke parts of icccm.

> And if you think no application today can avoid pulling in EGL or GLX,
> you're just wrong.

I don't think that and never said or implied it in any way.

> > And X11R6 added it.
> 
> Behind XInitThreads.  The old behavior of the library was intentionally
> kept for clients that did not use threads.
> 
>   (anecdotally, Emacs also did not require changes to work on R6.
>    Despite being a big and complex program that heavily mixed Xt and
>    Xlib code)
> 
> > various things broke/changed between x11r5 and x11r6.  Certainly parts
> > of ICCCM broke that required minor code changes in WMs and some
> > clients. the ICCCM has a nice list of them if you want to look it
> > up.
> 
> And which of those changes caused clients to freeze?

they would have caused other misbehavior or breakages like focus not
necessarily working right for example.

> In fact, which of those changes affected Xlib more than "new fields
> added to XSizeHints, which was documented as subject to extension"?
> 
> > They are not "new features to make use of voluntarily". They are
> > hard "must change your code" changes.
> 
> No, they were "new fields added to structs" changes.  Changes to the
> ICCCM naturally affected clients and window managers, but only if you
> used clients written for the new version of the ICCCM with those written
> for the old one.

one such example was using currenttime as opposed to the event timestamp for
XSetInputFocus (i ran into this myself at some point - reading old code
that used currenttime and then found r6 on needed to not do that). this would
require actual code changes to fix. the point remains the same. x11r6 broke
things that require either compiletime or runtime if/#if's.

> Motif programs, OTOH, were simply broken by Xlib 1.8.0, regardless of
> what other libraries they used.
> 
> > I remember dealing with this back then as there were still some x11r5
> > systems floating about that had some subtle differences. You're now
> > hitting another subtle change only really found now decades
> > later. There was obvious appetite for making small code breakages back
> > then and this here falls into that category.
> 
> Deadlocking Motif programs is not a "small change", and you cannot
> seriously compare it to the ICCCM 2.0.

it's pointing out that x11r6 broke things and code needed to be updated - not
just voluntarily opt into a new feature. that break already occurred. the x11r6
contract that says "don't call xlib calls inside this callback" has been around
for decades. this now actually produces a real side effect as opposed to no
visible side effect. the change in contract changed long ago.

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