X server crash recovery
Paulo Cesar Pereira de Andrade
pcpa at mandriva.com.br
Tue Oct 9 14:34:14 PDT 2007
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
More information about the xorg
mailing list