httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: [PATCH] Re: directory_walk performance
Date Thu, 02 Aug 2001 16:15:11 GMT
William A. Rowe, Jr. wrote:

>From: "Brian Pane" <>
>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
>>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
>>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
>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.
I don't think this is a new problem.  It's never been safe for a
dir_merge to blindly modify the base.  In directory_walk, the very
first call to ap_merge_per_dir_configs gets r->server->lookup_defaults
as its base, and the dir_merge shouldn't be modifying that.  Mod_mime
looks okay in this regard, with its copy-on-write logic; are there any
modules that don't treat the base as const?


View raw message