Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 34798 invoked by uid 500); 3 Jan 2001 00:09:36 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 34771 invoked from network); 3 Jan 2001 00:09:32 -0000 Date: Tue, 2 Jan 2001 16:11:54 -0800 (PST) From: rbb@covalent.net X-Sender: rbb@koj To: new-httpd@apache.org Subject: Re: cvs commit: httpd-2.0/modules/generators mod_cgid.c In-Reply-To: <20010102151312.G17220@lyra.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Tue, 2 Jan 2001, Greg Stein wrote: > On Tue, Jan 02, 2001 at 05:57:44PM -0000, rbb@apache.org wrote: > > rbb 01/01/02 09:57:44 > > > > Modified: modules/generators mod_cgid.c > > Log: > > Change a bunch of mallocs in mod_cgid to apr_palloc. These were never > > getting freed, and using malloc. This was safe, because we were in > > the CGID process, but pools are just safer here. > > Just curious: why would it be safe? Wouldn't the CGID working set grow > unbounded? Sorry, my bad, I wasn't clear at all. The data is actually read by the child of the CGID process, so it would die as soon as the CGI is done. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------