Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3EF811A7.5080908@algroup.co.uk>
Date: Tue, 24 Jun 2003 09:53:59 +0100
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB;
 rv:1.4) Gecko/20030529
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: response handlers get all requests
References: <OIECKMOJOMBCOBBGDMKAIEGDDHAA.mmadki@Doorways.org>
 <3EF76BA5.4090704@apache.org>
In-Reply-To: <3EF76BA5.4090704@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

gregames@apache.org wrote:

> Marc M. Adkins wrote:
> 
>>     The ap_hook_handler() call
>> does not specify the handler key from the corresponding AddHandler
>> configuration directive.  As a consequence, the specified handler
>> function
>> must look at and accept or decline each request.  
> 
> 
> yes, you are right.  IMO that sucks, for a number of reasons:
> 
> * the Apache 1.3 core was better about it and only called handlers when
> the request type matched a type the handler was interested in,
> 
> * we had to change the module API to accomodate this regression in the
> core, and
> 
> * now we have a distributed performance hit in 2.x, because the core is
> calling all these modules who don't care about the request which makes
> the CPU fetch crap instructions into the i-cache.  This won't show up as
> a hot spot in a profiler, because it is spread among all the different
> handlers and other code which is now taking more frequent i-cache misses.
> 
> ...but I'll shut up because I don't have a patch or a design for one yet.
> 
>> By contrast, output filters only see requests in which they have
>> interest.
> 
> 
> Clearly a better situation.

The change in handlers was made for a reason. The problem is, I've
forgotten the reason! A survey of all the existing handlers might well
reveal it - otoh, the reason might simply be that filtering hooks didn't
fit neatly with the new hook API. Which is, of course, fixable, at the
cost of some complication.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff