input thread [was Re: [PATCH v2] input: constify valuators passed in by input drivers.]

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100811/f998df8e/attachment-0001.pgp>