X server crash recovery

[Paulo Cesar Pereira de Andrade]

Daniel Stone wrote:
> On Mon, Oct 08, 2007 at 11:44:27AM -0300, Paulo Cesar Pereira de Andrade wrote:
>   
>>   I was considering ACPI as a possible alternative. But I am just 
>> studying and writing some experimental code. X should have at least the 
>> keyboard and video driver on different threads. The "smooth" mouse would 
>> probably also be better in a separate thread, other than using SIGIO.
>>     
>
> http://vignatti.wordpress.com/
> http://gitweb.freedesktop.org/?p=users/vignatti/xserver.git;a=summary
>
> Cheers,
> Daniel
>   
  Thanks Daniel. Actually I had looked a bit at the "Xat" this week, and 
http://www.c3sl.ufpr.br/multiseat/, but did not know about the multi 
thread input code. I talked via email with Tiago yesterday about this, 
and looked at some of the sources.
  Today I made a "quick hack" and put every input device on its own 
thread, i.e. not one thread for all input devices like Tiago's patch, 
and also, the keyboard input is also in it's own thread,
as what I want is keyboard response during a crash/lock, at least for 
some key combinations like Ctrl+Alt+Backspace.
  Actually, I am considering to also test the video driver in it's own 
thread, but it most likely would require more than a few semaphores at 
key points in mieq.c to keep consistency; well did not yet analise it...
  Mainly for better understanding of the code, I also #ifdef'ed all code 
that uses SIGIO, needed to also recompile a few modules, but these 
ifdef's I guess need to be removed for ABI compatibility.
  Another possible alternative may be to handle keyboard input using 
SIGIO, and/or some weird polling alarm() usage to try to detect a 
crash/lock.

  Anyway, I have the server running, now need to try to create a few 
test cases... But I guess I will at least find problems to do a clean 
exit this way, i.e. need to use "pselect" instead of select, and/or 
other ways to handle some special cases like uninterruptible system 
calls; probably set a flag to defer the exit, as it should always return 
from a system call or drm ioctl, and if it doesn't, then it is probably 
in a state that requires a reboot.

  As I told Tiago, I don't care much about latency in response, and this 
is a solution for a
problem that should not exist in the first place, i.e. the server 
crashing/locking.

Paulo