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. > Also realize that pthreads > support was only made mandatory in the 2008 version of POSIX. I don't > think it is a good idea to rely on it being available for another > couple of years or so. POSIX is, as they say, a trailing edge standard. Solaris grew pthread support in 2.5 in 1995, LinuxThreads was 1996ish, FreeBSD's libc_r was in 2.2.0 in 1997. Xthreads.h included pthread support from the moment it was released, which was X11R6 in 1994. I think it's pretty safe to assume by now that if you're even remotely unix, and you have a thread library, that it's pthreads. > 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. Anything beyond that is a bug that can already be triggered in the SIGIO path, given sufficient motivation. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
