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

[Adam Jackson]

On Thu, 2010-08-12 at 16:17 +0300, Vignatti Tiago (Nokia-MS/Helsinki)
wrote:
> 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.

Yeah, I should have been clearer here: eventfd is a pure optimization,
don't worry about it for the initial implementation.  Particularly since
Linux pipes are pretty dang fast already.

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

I do eventually want to see each ScreenRec factored out to its own
thread.  Right now in Xinerama rendering is serialized across all
screens, which is terrible.

If you did that, you'd have one thread for dispatch and core object
model, one for input, and one per GPU.  I don't think there's much value
in going beyond that for machines with reasonable GPUs.  In particular I
recommend avoiding the mistake MTX made of doing one thread per client;
once you do that you start needing a lock around every protocol-visible
object and the complexity doesn't actually win you any performance.

- 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/20100812/baa7a2c0/attachment.pgp>