Input thread on EVoC

[Peter Hutterer]

On Fri, Jun 04, 2010 at 12:28:51AM -0300, Fernando Carrijo wrote:
> On Thu, 03 Jun 2010 17:39:07 -0400, Adam Jackson <ajax at nwnk.net> wrote:
> > On Thu, 2010-06-03 at 20:40 +0100, Daniel Stone wrote:
> > >
> > > If you're really (really, really) keen, you could try to thread not only
> > > input event generation, but event delivery. :) You could get away with
> > > it fairly easily at first[0] by just having a single mutex which is
> > > taken both by the input thread, and by any operation which modifies the
> > > window stack, input shape, etc, in any way.
> > 
> > ... and anything that touches the client's output buffer?
> 
> Sounds like a good plan!
> 
> Nevertheless, I wonder how many of Daniel's threefold "really" refer to the
> inherent complexity of threading event delivery, and how many of them concern
> the obviously huge amout of mechanical work needed to acquire and release the
> aforementioned mutex by certain of those routines which encompass the server
> dispatch tables. Any idea?
> 
> Digging deeper, I see that Tiago himself faced these same considerations
> during one of his participations on GSoC, having opted to a more
> conservative approach due to an unfortunate lack of time.
> 
>   http://vignatti.wordpress.com/2008/08/18/parallel-events-panic-with-x/
> 
> Deviating a little from the above: do you think that a multithreaded X server
> capable of servicing client requests concurrently is a realistic goal for the
> long run? 

long run - yes. short run - no. I'd rather see a simple threading
replacement for the current SIGIO approach and then build from there. We can
design to multithread everything but quite frankly, if we never have the
working code that seems a bit of a waste of time.

> In particular, do you foresee any possible devilish traps resulted by
> interactions between threaded event delivery and threaded request processing?

yes. there's even different definitions of "event delivery". for input
events, you're mostly fine as long as you take care of window structure
changes (resizes, stacking, mapping, etc.) for other events, the window
content matters too. I'd say one step at a time.
 
Cheers,
  Peter