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

[Mark Kettenis]

> From: Adam Jackson <ajax at redhat.com>
> Date: Tue, 14 Dec 2010 17:27:46 -0500
> 
> 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.

Thanks.

> > 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.

Yes, that is the additional locking that's necessary.  I'd say you'll
need a mutex that you lock in x86BlockSIGIO() and unlock in
xf86UnblockSIGIO() and lock/unlock around each event that you process
in the input thread.

I'm amazed that the diff worked at all without this.  I guess KMS/DRM
adds enough serialization.  So this really should be tested on a
multi-card setup with something like a non-KMS radeon driver.

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

There was at least one such bug in xserver 1.8.x.  I spent several
hours chasing it, but didn't find it :(.  Making the xserver
multi-threaded won't make finding these bugs easier.