httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Issues with ->pool in CGI environment
Date Sun, 25 Jul 2004 18:50:21 GMT
Joe Schaefer wrote:
> Stas Bekman <> writes:
>>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.
> I don't like the idea of having Apache::Request objects generate a
> subpools, where nothing else in libapreq2 uses nor requires a subpool.
> Even if we did, the name would surely be misleading, because the
> lifetime of objects created in this pool would be shorter than the
> request's lifetime, which will create new bugs that libapreq2 isn't
> designed to handle.
> FWIW it's also quite possible to do something like this
>   sub pool {
>     my $env = shift->env;
>     return $env if $env->isa("APR::Pool");
>     return $env->pool;   # Apache::RequestRec provides a pool method
>   }
> but that sort of begs the question- why do *any* of our objects
> need to expose a pool method?  We don't create pools in Apache::Request,
> and we don't use pool objects in our perl APIs.  They were just 
> thrown in because upload->fh needed a pool to open with "<:APR",
> but it turns out that the ->pool method I wrote doesn't work in CGI.

right. which is why I wrote the other para, which you've snipped:

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

View raw message