From dev-return-3795-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Aug 03 05:15:33 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 61996 invoked by uid 500); 3 Aug 2001 05:15:33 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 61985 invoked from network); 3 Aug 2001 05:15:32 -0000 Message-ID: <021501c11bdb$5b018aa0$02000100@sashimi> From: "Bill Stoddard" To: "APR Development List" References: Subject: Re: apr_bucket_destroy & APR memory management Date: Fri, 3 Aug 2001 01:15:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > 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