From dev-return-3815-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sat Aug 04 04:00:18 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 68711 invoked by uid 500); 4 Aug 2001 04:00:18 -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 68698 invoked from network); 4 Aug 2001 04:00:18 -0000 Date: Fri, 3 Aug 2001 20:57:51 -0700 From: "Roy T. Fielding" To: Cliff Woolley Cc: Bill Stoddard , APR Development List Subject: Re: apr_bucket_destroy & APR memory management Message-ID: <20010803205751.J1122@waka.ebuilt.net> Mail-Followup-To: "Roy T. Fielding" , Cliff Woolley , Bill Stoddard , APR Development List References: <021501c11bdb$5b018aa0$02000100@sashimi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: ; from cliffwoolley@yahoo.com on Fri, Aug 03, 2001 at 11:50:02PM -0400 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > 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