to thread the X server (?)

[pcpa at mandriva.com.br]

Quoting Tiago Vignatti <vignatti at c3sl.ufpr.br>:

> Hi,
>
> What I did so far is a separated thread that takes care only the
> injection stage on the X server queue. Who is interested with the
> results, please read some past posts in my blog. It is currently in a
> very good shape (synced with post-mpx merge, all input devices are
> inside the thread and etc). The implementation looks like this:
>
> thread #1 deals with
>     - injection of input events from devices
> thread #2 deals with
>     - processing of input events to clients
>     - requests from known clients (rendering things)
>     - new client that tries to connect (pretty easy to do)
>
> Now I am pondering the following:
> Model one:
> thread #1 deals with
>     - injection and processing of input events
> thread #2 deals with
>     - requests from known clients
>     - new client that tries to connect
>
> It would be very very nice to let both threads totally independents. But
> we cannot. The event delivery depends on the window structure and the
> first thread must always wake up the second. Also, sometimes the
> processing of events take a while and the injection of events stays
> stucked in this model. So I came with this another:
>
> Model two:
> thread #1 deals with
>     - injection of input events from devices
> thread #2 deals with
>     - processing of input events to clients
> thread #3 deals with
>     - requests from known clients
>     - new client that tries to connect
>
> With this way the first and the second thread become not so tied and
> given that I’m using non blocking fds to wake up each thread (through a
> pipe), the server “enjoys” the effect of threads. For instance, under
> heavy drawing primitives only thread #3 would wake up.
>
> Well, I had implemented both models here and it workish (occasionally
> seeing some segfaults probably due of some critical regions I forgot to
> lock — now the only mutex that exists is inside the server queue of events).
>
> It's hard to imagine other models mainly because the way X deals with
> clients are very tied in every piece of the server and it would require
> a lot of mutexes. But I’d love to hear anyone disagreeing with this and
> proposing something here!

  This sounds interesting. I am not very experienced with thread
programming, but how does it handle signals?  If I understand correctly,
the "fair scheduler" is replaced by the threads, but are mouse pointer
updates with SIGIO still done, or are they just enque'd?

  Maybe a model where the server would pause/sigsuspend, with or without
threads could be considered.

  I think it could be interesting if all input were handled using SIGIO,
and have the "keyboard" thread "unblockable". This would fix the major
problem of my custom patch:
http://svn.mandriva.com/svn/packages/cooker/x11-server/current/SOURCES/0504-SAVE_CONTEXT-Mandriva-Custom-X-Server-patch.patch
and:
http://svn.mandriva.com/svn/packages/cooker/x11-driver-input-keyboard/current/SOURCES/0006-Add-support-for-the-SAVE_CONTEXT-Mandriva-patch.patch
and the major problem is that if the server becomes stuck in some busy
loop, it probably also blocked SIGIO, and it becomes "unkilable" with
Ctrl+Alt+Backspace

  But depending on what it is doing, it may not be possible to make it
get out of the busy loop in any way (I mean, if possible to connect
via ssh, may not be able to kill it), like if it is repeatedly in*/out*;
not sure about reading/writing mmio.
  As long as SIGIO is not blocked for keyboard input, it should be possible
to at least get out of some busy loop where it is doing ioctls, but maybe
the video hardware will lock...

> === What make things so hard ===
>
> Debug a multi-thread program is really tedious, consequentially work in
> this kind of environment as well. And that could be a great argument to
> not accept an X server multi-threaded in upstream some day.
>
> The thing that most pissing me off is how gdb sucks to debug the server.
> I’m using the last version of gdb (6.8 version and from today’s
> snapshot) and it often hard lock my machine (I’m sure I had to reboot my
> machine a least 20 times today... sigh.) Sometimes it consumes 99% of
> CPU and sometimes it completely hangs my machine. Yes, this is really
> boring. Anyone knows some magic parameters in gdb to avoid this hard
> lock up? Anyway, the goal for long term is to let an option — at
> compilation time — to not use the input thread.
>
>
> Comments? Thank you,
>
> --
> Tiago Vignatti
> C3SL - Centro de Computação Científica e Software Livre
> www.c3sl.ufpr.br

Paulo