XInitThreads in library constructor breaks Motif!

[Po Lu]

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 

> 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.

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

> 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?

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.

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.