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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
