None of the command-line shells that I am aware of are multithreaded. In particular, even those shells that support "job control" (Control-Z, bg, fg, etc) do so via facilities (namely, fork, exec, signals, pipes and PTYs) that predate Unix threads.

Nor is Emacs multithreaded even though it is able to "do many things at the same time". (Again, it forks and execs external programs a lot and uses signals, pipes and PTYs to communicate with those external programs.)

My question is, Does the dominant implementation of the X11 protocol (X.org) use Unix threads -- in either the server or any of the client libraries?

If so, approximately when did it (or its ancestor, XFree86, or XFree86's ancestor) start doing so?

  • If active threads/processes > number of cores then performance is reduced compared to event driven programming. Feb 17, 2017 at 16:18
  • X.org is multi processor, as parts of it can run on the GPU. Also because the client is a separate process, it automatically makes use of at least 2 of the main cores. Feb 17, 2017 at 16:22

4 Answers 4

$ ps -eLf
root         1     0     1  0    1 19:25 ?        00:00:00 init [4]
root      1699     1  1699  0    1 19:25 ?        00:00:00 /usr/bin/kdm
root      1701  1699  1701  8    2 19:25 tty10    00:13:10 /usr/bin/X :1 vt10 ...
root      1701  1699  1703  0    2 19:25 tty10    00:00:00 /usr/bin/X :1 vt10 ...
root      1706  1699  1706  0    1 19:25 ?        00:00:00 -:1
root      1707  1699  1707  0    2 19:25 tty9     00:00:02 /usr/bin/X :0 vt9 ...
root      1707  1699  1710  0    2 19:25 tty9     00:00:00 /usr/bin/X :0 vt9 ...
root      1713  1699  1713  0    1 19:25 ?        00:00:00 -:0

answers your question, I think.

Nevertheless, the question seems to be mixing several things together - multithreading isn't about not using fork()/exec(). Threads share the same address space and if you want to run a different process you certainly don't want it to have access to the same address space. And if you decided not to use external programs (especially in the shell that since you mention it), you'd have to code all the functionality again.

Multithreading isn't a cure for everything. It can mostly be a cure only for well parallelizable problems actually - check wiki page for a nice short overview. Making a program multithreaded doesn't make it better, in most cases it makes it worse due to the bugs in synchronization code (if present at all).

  • How does the output of ps answer my question?
    – hruvulum
    Jun 8, 2013 at 16:13
  • 1
    There are two lines with PID value of 1701 and different LWP values - that means that the X server is running multiple threads (LWP stands for Light-Weight Process, aka thread). Also note that the commands are the same - a server running on VT10 serving display :1.
    – peterph
    Jun 9, 2013 at 21:41

in E. S. Raymond's book the author quotes .

The X server, able to execute literally millions of ops/second, is not threaded; it uses a poll/select loop. Various efforts to make a multithreaded implementation have come to no good result. The costs of locking and unlocking get too high for something as performance-sensitive as graphics servers. -- Jim Gettys

  • (for those who are interested in mentioned "book" - author means The Art of Unix Programming by E. S. Raymond)
    – Max
    May 17, 2022 at 16:48

As I understand it, nothing about X11 itself prevents multi-threaded clients, it's just that Xlib has some race conditions that just can't be eliminated. I'm taking that from XCB, I don't know from experience. XCB is an Xlib-layer library designed to be used with multi-threaded clients. So, it looks like X11 clients tend to be written as event-driven, near-real-time programs just because. There's no reason not to do threaded clients.


This is not a direct answer to the question, but I feel like it clarifies things, and it is too long for a comment.

I think, you should not compare UNIX threads to processes (fork()). This question seems to suggest that threads are somehow supersede processes, which is not true. Both of them have their advantages and disadvantages, and ultimately it is the programmer's decision, which to use, if any. The same goes for reimplementing.

Should there be and advantage of using threads, the basic tools would have been reimplemented, or at least there would be a fork that aims for it.

Personally, I think for a task like a shell, multiprocessing is the better alternative, since you get a lot of protection for your shell: the processes it starts can go wild, but it won't bring down the shell.

On the other hand, e.g. signals are delivered to all threads, so a threaded shell would have to be able to survive signals that are aimed at/created by the utility threads, while at the same time deliver those signals, because the utility threads may need them...

All-in-all: multiprocessing allows for better separation of shell and processes it starts, and gives more freedom to the processes started by the shell to have signals, and probably a bunch of other stuff I can't think of.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .