apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: apr_bucket_destroy & APR memory management
Date Wed, 08 Aug 2001 00:45:16 GMT
On Sat, Aug 04, 2001 at 12:14:28AM -0400, Cliff Woolley wrote:
> 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).

It only imposes the restriction that a routine cannot morph a bucket
without also morphing the contents of that bucket, which in some cases
means transferring the data and freeing the old allocation.

> 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.

I would think that the bucket memory allocator and the bucket memory
deallocator would have to be consistent.  Put it in the pool.

....Roy


Mime
View raw message