Re: Selecting the Handler [was: Time for 2.2?]

["William A. Rowe, Jr." <wr...@apache.org>]

I recall some discussion that the walk-through-every-registered-hook-provider
to resolve the handler is a pretty slowish/crufty way to handle that part of
the request processing.  Especially if everyone sets up the handler up-front
in the various request preprocessing phases.

The problem with leaving it to be 'snatched' in the handler is that nobody knows
this will happen when the evaluate a 'preprocessed' req_rec.  And, it's slow.

So perhaps it's time to deprecate req_rec::handler in favor of a handler_fn or
some other sort of hash, and make the handler phase 1:1 on the request?

Bill

Re: Selecting the Handler [was: Time for 2.2?]

[André Malo <nd...@perlig.de>]

* William A. Rowe, Jr. wrote:

> So perhaps it's time to deprecate req_rec::handler in favor of a handler_fn
> or some other sort of hash, and make the handler phase 1:1 on the request?

That sounds like a very good idea to me.
But how would you handle things like "handler1 returns DECLINED and handler2
takes over"?

nd

Re: Selecting the Handler [was: Time for 2.2?]

[gr...@remulak.net]

William A. Rowe, Jr. wrote:
> I recall some discussion that the walk-through-every-registered-hook-provider
> to resolve the handler is a pretty slowish/crufty way to handle that part of
> the request processing.  Especially if everyone sets up the handler up-front
> in the various request preprocessing phases
> 
> The problem with leaving it to be 'snatched' in the handler is that nobody knows
> this will happen when the evaluate a 'preprocessed' req_rec.  And, it's slow.

++1 in concept.  This creates a performance problem that is unlikely to show up 
in profilers because the extra cycles/i-cache misses are spread among all the 
handlers.

Not sure how to implement it, but it shouldn't be too hard.

Greg