[PATCH] xfree86: use a thread for the generation of input events

[Mark Kettenis]

> Date: Tue, 24 Aug 2010 22:26:42 +0300
> From: "Vignatti Tiago (Nokia-MS/Helsinki)" <tiago.vignatti at nokia.com>
> 
> > And then you'd build the server such that either or both of those two
> > functions is #define'd to 0.  Which we kind of already do for SIGIO
> > except it's a stub function instead of a #define.  If you do that then
> > you can make the malloc failure in t_i_r_d not a FatalError, although
> > you'd need to make any input from main thread take the mutex.
> 
> Yep, makes sense. However Peter mentioned a good point: that drivers
> will want to know if the server is assuming thread or SIGIO, mostly
> to do malloc tricks I guess. So we may want to just drop off the
> SIGIO code for once and enable always the threaded coded.
> 
> I'm wondering how this sounds for other platforms (I'm coding in Linux) and
> other DDX. Alan, Mark Kettenis, Jon Turney and others?

I'm sceptical about this.  For one thing OpenBSD has a userland
threads library.  This mostly works, but it has some nasty
side-effects because the library switches all file descriptors in
non-blocking mode.  This is especially nasty if you use fork(2), which
the X server does.

And of course threaded code is an order of magnitude more difficult to
debug than non-threaded code.