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 21:29:37 GMT
On Mon, 10 Jul 2000, Rodent of Unusual Size wrote:
> "Roy T. Fielding" wrote:
> > 
> > Aside from the above coolness for HTTP serving, there is nothing magic
> > about pools.  They can be used for filter-local storage provided that
> > the pool is as persistent as the filter, but they can't be used for
> > bucket data.  Buckets require their own memory allocation/sharing/
> > freeing.
> Please substantiate so I 'get it..'
> Regardless of whether I do eventually 'get it,' I propose that
> each bucket have a pool pointer for a sandbox for the filters,
> just as we now provide in just about every other passed-around
> structure.  If the data can't be kept in the pool, all right
> (though that's the part I hope to 'get') -- but each filter
> shouldn't have to create/destroy its own working area.

I'm confused.  With pools, each filter will have associate itself with
it's own pool, and thus create and destroy its own working area.  With
malloc/free the filters have to create/destroy the memory used to pass
around the data (done through the bucket API), but the working area can be
the pool in the request_rec.

I do not believe each bucket needs their own pool, because the
bucket_brigade has its own pool.  In general, buckets shouldn't be passed
around without a bucket_brigade.  This is why buckets don't have their own
pools.  I do mention in the comments that the pool in the bucket brigade
is used to limit the brigade's lifetime, although I can't remember right
now if I actually registered a cleanup for it.


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

View raw message