[PATCH 1/2] xfree86: use a thread for the generation of input events
suokkos at gmail.com
Thu Dec 16 07:39:32 PST 2010
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.
>> > 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:
>> 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.
More information about the xorg-devel