apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: bucket api patch
Date Sat, 02 Mar 2002 23:06:07 GMT
Cliff Woolley wrote:

>On Sat, 2 Mar 2002, Brian Pane wrote:
>>I'm starting to look through the code in detail now, and one
>>aspect of the API bothers me:
>>How is apr_bucket_free() going to figure out which apr_bucket_alloc_t
>>to return the block to?  All it has as input is a pointer to a
>>bucket, in void* form.  Some of the bucket types contain an
>>apr_bucket_alloc_t*, but not all of them.
>apr_bucket_free() knows nothing about buckets, so ignore the fact that a
>bucket contains an apr_bucket_alloc_t* (see below).  The block allocated
>by apr_bucket_alloc() will have internal information stored immediately
>prior to (or following?) the location returned from apr_bucket_alloc.  In
>other words, apr_bucket_alloc will over-allocate so that it has a few
>bytes for its own purposes.  You and I had talked about that a while back
>and agreed that that seemed a reasonable way to handle the problem.

Cool, I'd forgotten about storing the metadata stored right in
front of the block returned by apr_bucket_alloc(); that will solve
the problem very cleanly.

>The reason for the apr_bucket_alloc_t* in some bucket types is so that
>apr_bucket_foo_make() can know which allocator to use when the new bucket
>type needs to allocate storage for private bucket-type-specific structures
>(eg struct apr_bucket_file).  But *all* bucket types should have this
>pointer...  did I miss one?

apr_bucket_heap and ap_bucket_error, I think


View raw message