httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: filtering patches
Date Mon, 10 Jul 2000 19:41:04 GMT
On Mon, 10 Jul 2000, Rodent of Unusual Size wrote:
> wrote:
> > 
> > No, it can't.  The pool cannot be destroyed before returning from the
> > function.  We don't know that the rest of the filters have finished
> > with the data yet.
> Isn't the outward-bound data supposed to be stored in a bucket?
> I think we're talking about apples and oranges; I'm talking about
> filter-private memory, and you appear to be talking about the
> memory used to transmit the data into and out of the filter.
> Why can't each bucket have its own pool?  When the bucket gets
> dumped to the wire, the pool gets destroyed.  If there's some
> semi-pathological module along the way, like mod_gzip, that
> wants to get all of the buckets before passing any along,
> well, we'll have a lot of memory consumption anyway.

Each bucket could have it's own pool.  Then, we are talking about
implementing malloc using palloc.  Basically, each bucket will have to
create a sub-pool off of the request_rec's pool, and it will be used to
allocate memory for that bucket and that bucket only.  Then, when we are
done with the bucket, we destroy the pool.

This is the same thing as using malloc/free with register/kill cleanup,
except that we incur the penalty of creating and destroying
sub-pools.  There is no reason to use pools, because they have to be used
just like malloc/free.  We trade the penalty of two system calls for the
penalty of creating/destroying pools.

We also have more pools lying around, taking up unnecessary memory.

Plus, since the memory doesn't actually get freed, our pools will grow
bigger than necessary.

If we use malloc/free we don't have the penalty when a filter caches the
data, because we can write it to the disk, and free that memory.  Using
pools, we can write it to the disk, and destroy the pool, but that doesn't
actually free the memory, it just returns it to the free list.  Yes, we
can re-use that memory, but we then back to using palloc to emulate

It doesn't make any sense to emulate malloc/free with
create_sub_pool/destroy_pool.  We incur allocation penalties in either
case, and we use more memory in the pool case.

> > > You have in no way convinced me of any portion of your sweeping
> > > "pools will not work for filters" statement.
> > 
> > How about now?
> Now I think we're talking about the same thing -- but I'm
> still not convinced.

Getting warmer?

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message