On Wed, 2010-08-11 at 17:46 +0300, Tiago Vignatti wrote: > FYI, myself and Fernando have already a working tree with input generation > running inside a thread: > > http://cgit.freedesktop.org/~vignatti/xserver/log/?h=inputthread > > I don't expect/want reviews yet though. Right now we're discussing the method > of communication between threads (we're using a pipe, which seems too much for > it) and some proper test stills needed (hotplug, multiple mice, display > blanking, etc). Probably we're going to rearrange the commits in a more > human-readable form before send around.
Pipes are about as cheap of a notification mechanism as you can get and still be portable. On Linux the eventfd() API is a bit cheaper if all you need is signaling across thread boundaries, which looks to be the case for this work. I'm not aware of equivalent facilities on other platforms (at least, not without porting the main loop to something besides file descriptors). > This work would solve mostly of this SIGIO issues we have today, for instance > Daniel's argument to not use malloc()ing during signal handler would not be > valid anymore and cursor jumping when the server is in D state > (uninterruptible). Threads will help when we're in D state, but only to the extent that they're not blocked by the main server. If the server is holding a read lock for the input queue, we're still going to lose if we try to write to it from another thread. Which is fine! But the point is we have to audit for _some_ constraint no matter how we do input. Either we can't allocate in the signal handler, or we can't do blocking syscalls in the server while reading the input queue. Also remember that just because you can malloc from a thread doesn't mean you should. The malloc arena is a shared resource and there's a lock surrounding that (in most implementations), just like there'll be a mutex around the input queue. > Another random commentary: I just read also ajax trying to miraculously > workaround Xv stuff when SIGIO handling happens. I see the server has race > problems like this everywhere and seems that luckily we didn't reach so much > so far. Maybe now swapping SIGIO method by a thread would trigger those more > often. I am _completely_ in favor of switching Linux to input threads instead of SIGIO. But my primary motivation for that is that SIGIO is just fundamentally a lame API. Signal enqueue can happen any time between the last time the handler calls read() and when you finally rt_sigreturn(), but since SIGIO doesn't queue like an RT signal you lose that notification when you do sigreturn. So now you have a stuck event until the next SIGIO delivers. You can change the notification signal to be an RT signal but that just pushes the enqueueing problem into the kernel; eventually it runs out of space and reverts to non-queueing SIGIO. I suspect the other platforms would be happier too since they either don't support SIGIO or have hilarious floating-point save/restore bugs in their signal handler code. - 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
