© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
(In reply to comment #17)
> Only code using Xlibint.h matters. Applications (almost) never use
> Xlibint.h. Gdk and the various client-side extension implementations are
> the only code I'm aware of that we need to concern ourselves with. For
> those components, the question of whether the XTHREADS definition
> matches the one in Xlib matters.
[snip]
> > In particular it changes LockDisplay() & UnlockDisplay() from being
> > no-ops to checking for per-display lock_fns & using them if present.
> > Because Displays always have a lock_fns field regardless of whether
> > XTHREADS is defined, the XTHREADS-ed LockDisplay() & UnlockDisplay()
> > implementations are safe to use even with non-XTHREADS "Xlib". It's
> > only when the macros & members whose names start with an underscore,
> > e.g. _XLockMutex(), are used that a *requirement* for the XTHREADS-ed
> > "Xlib" ABI is created.
> That appears to be true, in practice.
[snip]
> > I'm basing all of this on examination of the libX11 code & headers, of
> > course - could someone point me to the official ABI document?
> Hah!
> Oh, you were probably serious. I think the official ABI document for
> Xlib these days is <email address hidden>.
> Regarding Xlib ABI, we muddle through the best we can.
What I was getting at is that the Xlib ABI is defined by, well, the Xlib ABI!
There are two "special cases" in conflict, which lead to the lock assertion issue that we've encountered:
1. Single-threaded applications with Xlib-based extension client-side code in them, compiled without XTHREADS defined.
2. Multi-threaded applications with a single Xlib client thread & one or more XCB client threads.
The problem arises from the decision to support (2) and the particular implementation which has been chosen, for the reasons we've discussed.
It seems to me that both (1) and (2) are unlikely scenarios, but there are evidently several applications which fall into (1), while (2) will presumably only arise in the special case where a single-threaded Xlib application loads a DLL that spawns threads to talk to the X server using XCB. I'd therefore question how likely (2) is to be useful, and therefore question the decision to break (admittedly internal(ish)) ABI-compatibility with classic Xlib.