to thread the X server (?)

[Tiago Vignatti]

Hi Paulo,

pcpa at mandriva.com.br escreveu:
>   This sounds interesting. I am not very experienced with thread
> programming, but how does it handle signals?  If I understand correctly,

Signal handlers are shared between all threads. OTHO, we can set signal 
masks when a thread is created to independently handle a given signal.


> the "fair scheduler" is replaced by the threads, but are mouse pointer
> updates with SIGIO still done, or are they just enque'd?

hum? I didn't get it right.

>   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...

In my approach no more SIGIO is used to fire the devices. We decided to 
do this because a signal does not interrupt a process in D-state, for 
instance impacting in a cursor flicker on the screen.


Thanks for the comments,

-- 
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br