The base config is created in cfg->pool (a child of process->pool.)
If we are supposed to merge into the r->pool, we need a copy. That copy gets
tagged with the r->pool
If we are then supposed to merge using the sub_req->pool, we need another copy.
That copy is tagged with that sub_req->pool.
If we start caching configs, each cached <Directory /> config needs it's own pool
(so it can be destroyed when the cache stales.) That cache->pool is different
than the base cfg->pool, so we must copy. When we take the cached config into the
request, cache->pool isn't r->pool, so again we copy.
Other than that, we can keep merging without copies. Otherwise we drop the hashing,
because it is a cpu buster.
Bill
----- Original Message -----
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 14, 2001 4:21 PM
Subject: Re: [PATCH] I prefer this... Re: [PATCH] for mod_mime seg fault in 2.0.23 :-)
>
> > -1 (veto) to both suggestions.
> >
> > This is getting obscene. We've lost all value of tables, since they can't be
>memcpy'ed,
> > they have to be reconstructed. This will be much slower than the original array
>code.
> >
> > Committers, please review dir_create() and dir_merge() patches more carefully.
>There
> > is a long tradition of configuration bugs due to these assumptions. The patches
>that
> > added copy/copy_mappings was an attempt to salvage this.
> >
> > I'll demonstrate a solution, using pool scopes, that adds safety and speed. Give
>me a
> day.
>
> What are pool scopes?
>
> Bill
>
>
