> From: Adam Jackson <[email protected]> > 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
