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 Sat, 04 Aug 2001 03:57:51 GMT
> The problem is simple: until we have SMS, all apr_bucket structs _must_ be
> allocated with the same allocator (malloc) and therefore freed with the
> same function (free).  Why?  Because the apr_bucket struct is not type
> specific and actually frequently changes types.  Any time we morph from
> one bucket type to the next, we take an apr_bucket that was allocated by
> one type's _create() function and just reset its ->type and ->data
> pointers.  If each type gets its own free function, we might have an
> apr_bucket that was allocated by one bucket type using one allocator that
> gets morphed to another bucket type.  Calling free on that apr_bucket is
> now an invalid function.  Working around this problem without SMS requires
> inserting a lot of special cases anytime we attempt to morph.  How does
> SMS help?  Because with SMS, each apr_bucket struct will get an ->sms
> pointer that indicates what SMS was used to allocate that bucket (so that
> the private structures for the bucket can be allocated in the same SMS).
> THAT's the sms to use when freeing that apr_bucket, and it won't change
> if/when we morph that bucket to a new type.
> 
> Unless you can think of a clean way around this problem, I think we need
> to back out this patch.

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.

....Roy


Mime
View raw message