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 03:50:02 GMT
On Fri, 3 Aug 2001, Bill Stoddard wrote:

> > +0.9 It should be really easy, in fact... just stick free itself in for
> > that function pointer in all currently implemented bucket types.
> Okay. If I hear no dissents, I'll do it tomorrow.

I was in the process of cleaning up some of the comments in apr_buckets.h
about the various function pointers and what they do, and I thought of a
big big problem with this.  I have to negate my vote to -0.9.  :-(

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.


   Cliff Woolley
   Charlottesville, VA

View raw message