Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 61208 invoked by uid 500); 21 Dec 2002 15:45: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 61193 invoked from network); 21 Dec 2002 15:45:49 -0000 Date: Sat, 21 Dec 2002 08:01:52 -0800 (PST) From: X-X-Sender: To: Brian Pane cc: Cliff Woolley , , APR Development List , Sander Striker Subject: Re: [PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator In-Reply-To: <1040455438.1638.74.camel@desktop> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 20 Dec 2002, Brian Pane wrote: > On Fri, 2002-12-20 at 22:03, Cliff Woolley wrote: > > > Can we at least agree to do one thing: > > release 2.0.44 *without* Brian's change. > > Okay with me. I am vetoing this change until I get a clear description of the problem it is solving. I have explained multiple times why it is a bad change, but I can't offer any other solutions until I know why it is needed. > > Then we can sort out the best > > course of action without delaying the entire release process on the stable > > branch. It might well be that the best course of action is to just fix > > the places in httpd that abuse brigades. But as Bill pointed out, what > > about third party modules? Ay caramba. > > FirstBill's patch should allow third party 2.0.x modules to work. It will not. If you _ever_ create a brigade with a NULL pool, you will have memory leaks. I dare say that every filter ever written will leak if the feature implemented with this patch is ever used. I have already posted one code segment in the core_output_filter that proves the memory leak exists. Trust me when I tell you that there are hundreds more, and some of them are in 3rd party modules that you don't control. > > +1 to moving brigades back into httpd, fwiw. > > +1 ++1, but they should go into an external library so that projects like serf have access to them. Happily, I don't have to worry about that. Ryan