On Thu, Dec 16, 2010 at 12:08 AM, Mark Kettenis <[email protected]> wrote: >> 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.
valgrind --tool=helgrind might help with multi-threading. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
