[PATCH 3/3] xfree86: Add a conservative SIGIO handler path

[Vignatti Tiago (Nokia-MS/Helsinki)]

On Tue, Oct 19, 2010 at 09:41:20PM +0200, ext Adam Jackson wrote:
> On Thu, 2010-10-14 at 16:26 -0300, Tiago Vignatti wrote:
> > On Thu, Oct 14, 2010 at 06:49:06PM +0200, ext Adam Jackson wrote:
> > > Instead of actually processing input in the handler, the conservative
> > > path just raises enough of a dispatch exception to bomb out of request
> > > processing and handle input instead.
> > 
> > ajax, I understand the rationale but would be great if you elaborate a bit
> > defending why we need _another_ method here. We're adding more complexity and,
> > for instance, we would have to justify the removal of this new method when
> > introducing the input-thread given I was already assuming like dead all SIGIO
> > paths.
> > 
> > So, to better accomplish this all, we need to perform and benchmark:
> > 1. input thread
> > 2. aggressive SIGIO (current one by default on linux) 
> > 3. conservative SIGIO (raising up isItTimeToYield)
> > 4. old input processing using the main thread handler
> > 
> > Do you have some thoughts on those?
> 
> Actually, what I want to see is:
> 
> 1: input threads if you have working threads
> 2: classic-ish input processing if you don't, with something like the
> conservative SIGIO handler as a helper if your platform has SIGIO
> support

I see.

 
> Which should be a material improvement for everybody, even if it doesn't
> reduce the number of code paths it's at least no more complex than what
> we have.

I'm not that convinced yet that conservative's SIGIO approach performs better
than the method using main thread handler. For instance, I'm afraid that it
could penalize too much other running X requests.

Anyway, I'd like to ask if you can hang these patches for more one week until
I come with numbers benchmarking all these different approaches.


Cheers,
             Tiago