httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] I prefer this... Re: [PATCH] for mod_mime seg fault in 2.0.23 :-)
Date Tue, 14 Aug 2001 21:34:24 GMT
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" <bill@wstoddard.com>
To: <new-httpd@apache.org>
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
> 
> 



Mime
View raw message