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

[Adam Jackson]

On Mon, 2010-12-13 at 21:19 +0100, Mark Kettenis wrote:

> First, the autoconf bits suggest that the input thread is optional.
> But I can't see any evidence of that in the code changes.  I really
> *don't* want a threaded X server on OpenBSD, but with this diff the X
> server has to be linked against libpthread and will call
> pthread_create(), which is really bad.

Yeah, that's unintentional, --disable-input-thread should give you a
silken-free server.  Will fix.

> Also realize that pthreads
> support was only made mandatory in the 2008 version of POSIX.  I don't
> think it is a good idea to rely on it being available for another
> couple of years or so.

POSIX is, as they say, a trailing edge standard.  Solaris grew pthread
support in 2.5 in 1995, LinuxThreads was 1996ish, FreeBSD's libc_r was
in 2.2.0 in 1997.  Xthreads.h included pthread support from the moment
it was released, which was X11R6 in 1994.  I think it's pretty safe to
assume by now that if you're even remotely unix, and you have a thread
library, that it's pthreads.

> Second, how does the silkenmouse behaviour actually work with this
> diff?  The event queueing stuff is a bit of a maze, so I'm not sure
> how it actually works, but either:

The intent, after this series, is that silken means input thread instead
of SIGIO; the SIGIO handler code still exists, but serves only as an
accelerator to get the main loop from handling requests to handling
input.  This is what I proposed (and you endorsed) a few months ago:

http://lists.x.org/archives/xorg-devel/2010-October/014028.html

Since signal delivery can happen between any two userspace instructions,
we're not adding any additional races to the extent that the code that
runs in the signal handler is atomic with respect to the rest of the
server.  The mi event queue is protected by a mutex, so that's clean.

But, in fairness, we should be turning most of the existing calls to
xf86BlockSIGIO into something that will rendezvous with the input thread
to halt input processing, since those are the existing critical sections
around which we know async input handling is unsafe.  I'll fix that.

Anything beyond that is a bug that can already be triggered in the SIGIO
path, given sufficient motivation.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101214/7284620c/attachment-0001.pgp>