Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <17b001c11b5b$debe1e60$93c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <new-httpd@apache.org>
References: <3B33B2B2.40800@pacbell.net>
 <114401c11ab2$348fe170$93c0b0d0@roweclan.net> <3B691549.7040306@pacbell.net>
Subject: Re: [PATCH] Re: directory_walk performance
Date: Thu, 2 Aug 2001 09:01:42 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Status: O

From: "Brian Pane" <bpane@pacbell.net>
Sent: Thursday, August 02, 2001 3:54 AM


> William A. Rowe, Jr. wrote:
> 
> >  see my commit to core/request.c ... I've dropped in the new directory_walk
> >code.
> 
> Here's a patch that implements my pre-merge optimization to
> reduce (and in some cases completely eliminate) the calls to
> ap_merge_per_dir_configs.  Its impacts on directory_walk are
> minor; all the real work happens in a new post-config-phase
> function.
> 
> I was able to generalize the pre-merge technique to support
> even wildcard directories (something that my original prototype
> couldn't handle correctly).  The comments in core.c describe the
> algorithm.

There is one _huge_, glaring omission (not in your patch).

If we optimize an individual module dir_merge (see the tables in mod_mime)
and the optimizer comes along and holds a partial merge, that cached merge 
_may_ become corrupted when we try merging along the complete context in
the r pool.

This change will require all dir_merge operaions to be told if it is merging
a final (cached) copy, or an incremental (the request, or part of a cached
copy that isn't the end-node).  The dir_merge must be certain it doesn't modify
anything in the working base if that base has come from the config rec or the
cache.  Contrawise, it _may_ modify the base if the caller will be discarding
that base.

Bill