Not to thread the X server

[Juliusz Chroboczek]

> good point. In fact, we would have to characterize the workload of
> a common usage and see if the currently scheduler is fair
> enough. A new dynamic/adaptive scheduler would be also cool.

Tweaking the scheduler won't help much if there are long-lived
requests.  What would be cool would be the ability either to suspend
a request in the middle of its execution and use a block handler to
resume it after servicing input events and other clients, or to have
the main loop delegate the execution of a CPU-bound request to
a thread pool.

> Now a question that I want to know is: what is more desirable to the
> kernel efficiently schedule (in terms of context switch, etc):
> a signal interruption or another thread?

I don't have any data handy for signals, but I can say for sure that
nptl context switch on a modern Linux kernel on x86 is surprisingly
fast, as fast as the fastest user-space thread libraries.  Have a look
at Figure 2 on page 8 of

    http://www.pps.jussieu.fr/~jch/cpc.pdf

                                        Juliusz