apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: apr_bucket_destroy & APR memory management
Date Fri, 03 Aug 2001 05:15:42 GMT
> On Thu, 2 Aug 2001, Bill Stoddard wrote:
>
> > Fix 1... Pass the entire bucket to the destroy function and let
> > destroy free the bucket right before return.
> > #define apr_bucket_destroy(e) do { \
> >     e->type->destroy(e); \  /* e is freed in destroy() */
> > } while(0)
> >
> > One irritation with this method is that the destroy() function is
> > called internal in many of the bucket functions (search for
> > file_destroy() in apr_bucket_file to see what I mean).
>
> That's the whole problem, yeah.  -1.
>
>
> > Fix 2 Define a new field in the generic bucket structure, a pointer to
> > a function to free the bucket. For example:
> > #define apr_bucket_destroy(e) do { \
> >     e->type->destroy(e->data); \
> >     e->type->free(e); \
> > } while(0)
> >
> > This requires each bucket implement a free() function.
> >
> > Any strong opinions on which way to go (or suggestions for an entirely
> > different solution)?  I'll implement whichever one the group decides
> > on.
>
> +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.

>
> However: once we switch buckets to use SMS, none of this will really be
> necessary... s/free/apr_sms_free/ in the apr_bucket_destroy() macro, and
> then SMS handles the polymorphism for you.  Just a thought.

Quite interesting! Still, I think it makes sense to have bucket specific free functions.
This is exactly analogous to a class destructor, which lives inside, not outside, the
class.

Bill


Mime
View raw message