From dev-return-8794-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Dec 20 18:28:58 2002 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 53954 invoked by uid 500); 20 Dec 2002 18:28:57 -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 53735 invoked from network); 20 Dec 2002 18:28:56 -0000 Subject: Re: [PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator From: Brian Pane To: rbb@apache.org Cc: Bill Stoddard , dev@httpd.apache.org, APR Development List In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1040408658.1199.17.camel@desktop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 20 Dec 2002 10:24:18 -0800 Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 2002-12-20 at 08:57, rbb@apache.org wrote: > I am actually pretty sure that allocating brigades out of the > bucket_allocator is a VERY big mistake. In fact, I am close to asking > that change to be backed out because it is too dangerous. > > When we first designed buckets and bucket brigades, we made one VERY clear > distinction. Bucket_brigades are allocated out of a pool, because that > stops us from leaking memory. Allocating brigades from a pool is often a design mistake. Brigades tend to outlive the transactions that produce them (especially in apps like http servers), and having a brigade disappear as a side-effect of a transaction pool's cleanup will cause problems elsewhere in the code. > By allocating bucket_brigades out of the bucket_allocator, we have removed > the protection that the pool cleanups used to give us. It's important to keep in mind just what sort of protection the pool-based brigade allocation offered. It allowed code that did this: bb = apr_brigade_create(...); apr_brigade_destroy(bb); APR_BRIGADE_INSERT_HEAD(bb, bucket); to work accidentally. I'm hesitant to call that "protection." Brian