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
