Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 80294 invoked by uid 500); 2 Jul 2003 06:38:50 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 80270 invoked from network); 2 Jul 2003 06:38:49 -0000 Date: Wed, 2 Jul 2003 02:37:58 -0400 (EDT) From: Cliff Woolley X-X-Sender: root@deepthought.cs.virginia.edu To: dev@httpd.apache.org cc: dev@apr.apache.org Subject: Re: cvs commit: apr-util/include apr_buckets.h In-Reply-To: <20030702063719.GA20091@lyra.org> Message-ID: References: <20030702052544.98831.qmail@icarus.apache.org> <20030702063719.GA20091@lyra.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 1 Jul 2003, Greg Stein wrote: > Eh? Why the flag? What is that for... doesn't the caller know when and if he > should clean up? So there shouldn't be a need for a flag... The caller knows. But right now apr_buckets_alloc.c:alloc_cleanup() calls apr_allocator_destroy(allocator) regardless of whether it "owns" the allocator or not. But I think this is irrelevant because I think there's an entirely cleaner way to do this. No flag, no extra API function. Namely, we should just have apr_bucket_alloc_create(apr_pool_t *p) {} use p's allocator always (apr_pool_allocator_get(p)). I think that will work fine and solve this problem for good. But I have to think about the ramifications. From what I've seen of the MPM's in looking through them just now, I think it will be okay. But I'll need to investigate further to be sure. --Cliff