You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2001/01/03 00:13:12 UTC
Re: cvs commit: httpd-2.0/modules/generators mod_cgid.c
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?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/generators mod_cgid.c
Posted by rb...@covalent.net.
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
-------------------------------------------------------------------------------