httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: Optimizing dir_merge()
Date Tue, 11 Sep 2001 03:39:53 GMT
On Wed, 15 Aug 2001, Brian Pane wrote:

> William A. Rowe, Jr. wrote:
> >Here's my take on the dir_merge patch I offered up.  Please review for sanity.
> >
> Thanks!  This looks clear and complete to me.
> There's one point at the end where I disagree, though it may be due to
> a bad assumption on my part.  Here's the item in question:
> [...]
> >Caching Considerations
> >----------------------
> >
> >The key point within Apache is; a given per-dir config cannot be trusted after a
> >subsequent merge_dir_configs callback in the same pool.
> >
> I wouldn't have drawn this conclusion.  If your per-dir config is being
> passed as
> the 'base' to a subsequent merge_dir_config callback, it should be
> unharmed afterward
> because the callback must treat the base as const.  It's okay for the
> callback to
> use a very liberal definition of constness if needed for performance
> reasons; e.g.,
> it can increment a reference count in the base in support of
> copy-on-write logic.

writing base is a bad idea in the prefork case, because most of the base
entries (i.e. all from httpd.conf) are in CoW regions shared with all
other child processes/parent.  when you start writing you multiply that
cost by the number of children.  this nails your caches with lots of
essentially duplicated data, and you'll lose any benefit is my guess.

however, what you can probably get away with is putting a pointer to a ref
counter into base... and allocate an array of ref counts.  then you're
only duplicating that one page.

but actually i'm not sure why you need ref counts to begin with -- because
i think that it is always the case that base is from an ancestor pool of
the mergee... so base should exist at least as long as the mergee does.

> But from the perspective of the caller, passing a cached per-dir config
> as the
> base to a merge_dir_configs callback shouldn't change the semantics of
> the data
> in that per-dir config.
> What am I missing?

you're not missing anything...

the merge functions are essentially supposed to be idempotent.


View raw message