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
-------------------------------------------------------------------------------