apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: apr_bucket_destroy & APR memory management
Date Sat, 04 Aug 2001 04:14:28 GMT
On Fri, 3 Aug 2001, Roy T. Fielding wrote:

> If you can morph a bucket type to another bucket type, then you already
> know what the two types are and hence whether or not they will have the
> same free function.  Otherwise, the act of morphing is already broken,
> since it is already making a lot more assumptions than allocation source.

There's still a problem with that, though.  Take this typical situation:

   e = apr_bucket_foo_create();
   apr_bucket_read(e);
     ...  morphs to type bar
   apr_bucket_destroy(e);
     ...  calls ->type->free() pointer from bar, not foo

This imposes a lot of potentially nasty restrictions: (a) the original foo
apr_bucket must have been allocated with the same type as a bar apr_bucket
would be allocated with, (b) foo buckets can never support morphing to
both bar1 buckets and bar2 buckets simultaneously if bar1 and bar2 use
different allocators, (c, which follows from a and b) neither foo nor bar
buckets, which have the same, non-standard allocator due to restriction
(a), can ever be morphed to a standard bucket type (eg heap, which is a
staple of morphing), due to restriction (b).

The only way out of this dilemma that I can think of I hate, which is to
put the ->free pointer in the apr_bucket rather than in the
apr_bucket_type_t.  That sucks.  If you've got a better idea, I'm all
ears.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Mime
View raw message