Why Isn't X11 Thread-Safe?

blackcoot asks: "I've just spent a couple very frustrating days trying to figure out what 'unexpected async reply' means and fixing it. The problem is a result of the fact that X11 simply isn't designed to handle events from more than one thread at a time. Why? Given that more and more often, people are writing multi-threaded GUI applications, are there fundamental design decisions in X11 that make dealing with receiving events from multiple threads simultaneously, impossible? Or was the protocol never designed to handle concurrent updates? More to the point, is there an easy way in Qt (short of deriving a new widget for every widget and overriding it's paintEvent to lock the library first, paint, then unlock as Trolltech's docs seem to suggest) to make this problem go away?" I'm not sure if things have been done in recent revisions of XFree to fix this problem, but this message, from February of last year, might help some of you out that are suffering from this problem. Any ideas if this problem has been fixed in recent versions of XFree?

Comments

What I do

[Procyon101]

What I do is create a GUI thread which handles all interface to the GUI. All of my other threads then fire their events to that thread through an interface that IS threadsafe. The GUI thread then synchronously handles the GUI events. This abstraction away from your actual GUI API allows you to more easily port your app to another platform because all of your X11 specific code is contained in one place.

Re:What I do

[mike_sucks]

Yeah, I think having a single GUI thread per app is pretty much standard for all the environments I've programmed for.

There's absolutely no need for a display system like X to allow multiple application threads to concurrently recieve events and/or update the application's display. It would just add unnesessary complexity, making it harder to debug and maintain.

Also, having a single GUI thread is a good design pattern. All GUI work is handled by one thead, all application logic is (potentially) handled by other threads. The delineation between the application's UI and logic makes it much easier to maintain.

So yeah, blackcoot shouldn't complain that X is broken, I'd say whatever app {s}he is writing needs to get fixed.

Re:X sux and is the biggest thing holding back lin

[JohnFluxx]

Why do you think X sucks?

It is a very impressive protocol - just consider how long it has been around, and you can do just about anything without breaking it.
How many other protocols are there that can boast that?

What can't X do?

Re:It has been for almost a decade ... not quite

[nathanh]

Xlib was made thread safe in the X11R6 [uni-bremen.de] release in 1994, but only if you initialize the locks it needs to do it properly via XInitThreads [xfree86.org].

Xlib is thread safe but X11 is not. If your application has multiple threads then they must compete for the "display lock" with XLockDisplay and XUnlockDisplay. In other words, Xlib is used to solve the thread unsafety of X11. It's a library space (Xlib) solution to a protocol (X11) limitation.

So while you are right - Xlib is thread safe - you weren't answering the original question which is Why Isn't X11 Thread Safe? The answer is that it's not possible. He might as well ask why HTTP isn't thread safe, or why SMTP isn't thread safe. Imagine muxing two HTTP requests into a single request! It'd look like this:

GET /GET /index.htpage.asmlp HTTHTPTP/1./1.00

It's not an issue for the protocol to solve. This is why it's a non-problem. The questioner is simply confused. You don't make a protocol thread safe. You make the library calls to the protocol thread safe, and as you point out this has been solved with XFree86 for almost a decade.

Qt is thread safe

[frezeal]

If you link against libqt-mt, you can post events outside of the main event thread. You still shouldn't call methods directly on QtWidgets. But the link should answer all of your questions and solve your problem.

http://doc.trolltech.com/3.0/threads.html

Don't Bother

[Markus Registrada]

There's no reason for the X wire protocol to be "thread-safe" (i.e. atomic/transactional). There's not even any need to use locks in Xlib.

A multithreaded program may simply open several connections to the X server, and operate independent UIs. One thread might operate a display window, while another operates a dialog box or progress bar. As far as X is concerned, it's talking to different programs.

Don't go looking for complicated solutions when simple ones are right at hand.