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

[Vignatti Tiago (Nokia-MS/Helsinki)]

On Wed, Aug 11, 2010 at 08:04:08PM +0200, ext Adam Jackson wrote:
> 
> 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).

all right. I think we're going to just stick with pipes for now and further on
we can discuss a better method. I carefully tested the multi-processing effect
between both threads and seems to be working nicely; so yeah, I'm already
happy with pipes.

 
> 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.

I could run some tests here but I'm pretty sure we're going to have just a few
block happening in the mi queue. Even so if this is the case, it's gonna be
for a very short time, because we just lock the queue accesses, not going to
anywhere deeper.


> 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.

Okay, good to hear.

I do agree the input generation thread is not something extraordinary, which
would bring some nice and apparent performance. The main benefit probably is
that will be opening space to other thread works. One might want to thread the
X rendering or maybe bring up all keyboard mapping to generation as well - is
that possible?. Also, I envision some code organization creating some sort of
/inputgeneration directory separating everything related with it (ptrveloc.c,
getevents.c, part of xf86Events.c, etc). Well, threading is just an easy way
to think all X input processing implementation.


Thanks for sharing your thoughts ajax!

             Tiago