Comment 61 for bug 86103

Revision history for this message
In , Josh Triplett (joshtriplett) wrote :

Things that happened to work with some versions of Xlib != things that Xlib supported. If you use Xlibint to write an X extension, regardless of whether that extension lives in a library or directly in a program, your extension code must match the system Xlib's idea about threading. This held true for Xlib regardless of whether any particular version of Xlib let you get away with not doing it; Xlib has in the past had notoriously lax ideas about threading.

Xlibint has existed for a long time, and people have used it; we do understand that has for some time formed part of the "public" API/ABI of Xlib. However, that doesn't make every detail in Xlibint part of the ABI. For example, Xlib/XCB, as well as older versions of Xlib, have extended the Display structure, so you cannot count on sizeof(Display) never changing. That does not represent part of the ABI, despite the fact that changing it could potentially break code which made assumptions about sizeof(Display), because code should not make assumptions about sizeof(Display). The same applies to the locking hooks; you must check and use them, and you must not simply assume that Xlib will not set them if you don't call XInitThreads.

As you have suggested, building your extension code with XTHREADS may work with older Xlibs that do not use XTHREADS. However, building your extension code without XTHREADS will break with an XTHREADS Xlib. I understand your argument that older versions of Xlib didn't actually use internal locking and unlocking code if you didn't call XInitThreads(), and thus you could get away without even trying to call them; however, that does not mean that you do not need to call the macros which check for the internal lock and unlock function pointers and call them if set.