XInitThreads in library constructor breaks Motif!

[Carsten Haitzler]

On Tue, 01 Nov 2022 08:55:50 +0800 Po Lu <luangruo at yahoo.com> said:

> Carsten Haitzler <raster at rasterman.com> writes:
> 
> > 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.
> 
> No, it doesn't, see below:

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

> > 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 my program does not use XCB (or even link with X11-xcb), why should
> it be subject to constraints placed by XCB?  XCB is just one transport
> for the X library.

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

> > 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.
> 
> Nonsense.  The X library has worked how I (and Motif) expect it to since
> at least the early 90s.
> 
> The X11R5 manual page says:
> 
>     The XIfEvent function completes only when the specified predicate
>     procedure returns  True for an event,  which indicates an event
>     in the queue matches.  XIfEvent flushes the output buffer if it
>     blocks waiting for additional events.  XIfEvent removes the
>     matching event from the queue  and copies the structure into the
>     client-supplied XEvent structure.
> 
>     When the predicate procedure finds a match, XCheckIfEvent copies
>     the matched event into the client-supplied XEvent structure and
>     returns  True.  (This event is removed from the queue.)  If the
>     predicate procedure finds no match, XCheckIfEvent returns False,
>     and the output buffer will have been flushed.  All earlier events
>     stored in the queue are not discarded.
> 
>     The XPeekIfEvent function returns only when the specified
>     predicate procedure returns  True for an event.  After the
>     predicate procedure finds a match, XPeekIfEvent copies the
>     matched event into the client-supplied XEvent structure without
>     removing the event from the queue.  XPeekIfEvent flushes the
>     output buffer if it blocks waiting for additional events.
> 
> Notice how there is no mention of calling Xlib functions being unsafe,
> as at that point the X library did not have thread support at all.

And X11R6 added it. 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. They
are not "new features to make use of voluntarily". They are hard "must change
your code" changes. 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.



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