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

[Pauli Nieminen]

On Thu, Dec 16, 2010 at 12:08 AM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>> 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.

valgrind --tool=helgrind might help with multi-threading.