to thread the X server (?)

[Paulo Cesar Pereira de Andrade]

Tiago Vignatti wrote:
> Hi Paulo,
  Hi Tiago

>>   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?
s/fair/smart/. By enqued I mean there is no update of cursor position
from the signal handler, to give the impression of a smooth cursor, even
if the server is under heavy load.

> 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.
  Let me see if I undestood... One thread (p)select on the descriptors,
and wake another using a pipe?

> Thanks for the comments,
  No problems :-)

Paulo