httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: Issues with ->pool in CGI environment
Date Sun, 25 Jul 2004 16:14:44 GMT
Joe Schaefer wrote:
> While working on Cookie.pod I came across
> a problem with the ->pool methods.  What happens
> is that (in CGI context) because the environment 
> object is a pool created by APR::Pool, it is marked 
> for destruction via DESTROY.  However methods like
> $cookie->pool() and $upload->pool() generate new
> objects that point to the same apr_pool_t, and when
> those objects go away, that triggers the pool's 
> destruction.

How about this solution. Have libapreq provide a pool class method, 
which will create a new pool, bypassing APR::Pool->new(), or 
sub-classing it. It should be safe in mod_cgi env, since the pool gets 
destroyed at the end of each run. In the mod_perl mode it should just 
return $r->pool instead, so the external API is identical.

In fact you could completely eliminate the pool argument from all 
libapreq calls, and handle it internally. Instead $r should be passed if 
it's mod_perl, or something like that.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message