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. – ctrl-alt-delor Feb 17 '17 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. – ctrl-alt-delor Feb 17 '17 at 16:22
$ 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).

| improve this answer | |
  • How does the output of ps answer my question? – hruvulum Jun 8 '13 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 '13 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


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.

| improve this answer | |

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.