Not to thread the X server [was: to thread the X server]

[Juliusz Chroboczek]

>> I appear to have missed part of the discussion.  Why are you trying to
>> multithread the X server?  It will cause a lot of subtle bugs, and
>> I don't see what it will buy you.

> Here, Juliusz: http://vignatti.wordpress.com

Thanks, Tiago.

Reading everything since 16 June, here's what I gathered.  Let me know
if I got anything wrong.

The fundamental goal of this work is to avoid the mouse pointer
lagging behind the mouse.  In the traditional X11R5 implementation,
the mouse cursor will lag if WaitForSomething is not called often
enough.  This can happen for two reasons:

1. the server is stuck executing some long-lived request, such as
   a large PolyLine, font rasterisation, or a GLX request; or

2. the server code is not executing at all because it is swapped out.

You (rightly) mention that Keith's SilkenMouse hack (moving the mouse
pointer in sighandler context) mostly solves issue (1) by allowing the
pointer to move even when WaitForSomething is not being called.  You
justly note that it only works when the mouse pointer is a hardware
sprite, but that is usually the case nowadays.

(Something that you do not mention is that the issue of long-lived
 requests is mostly a thing of the past.  PolyLines are not that
 common, fonts are mostly client side, and OpenGL is usually client-side
 due to DRI.)

So what remains is case (2), the X server getting swapped out.  You
have found out that putting the mouse code in a separate thread does
not help much, since the thread's code is being swapped out together
with the rest of the server.  Your solution is to mlock parts of the
server, but you're finding it difficult to find out which parts exactly
need to be mlocked.

(The conclusion below is from me, not claiming to reflect Tiago's write-up.)

I'm still convinced that using threads in the X server is a bad idea.
However, now I at least understand what you're trying to do.  I remain
convinced that a better approach to improving the server's latency is
to move more stuff to the client side, so that the clients, rather
than the X server, get swapped out, and banging client authors on the
head until they stop allocating humonguous server-side structures
(yes, Firefox, that means you).

                                        Juliusz