You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2004/07/24 21:04:35 UTC
Issues with ->pool in CGI environment
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.
We have the same problem with ->env in CGI context,
but that is fixable because we keep a copy of the
original environment sv. However this won't work
for ->pool, because the environment's sv isn't
always representing a pool (in mp2 case it's a
request_rec pointer).
Unless someone has a real desire to fix ->pool,
I plan we drop this method as being more trouble
than its currently worth. Recall that I only
put it in because ":<APR" requires a pool object,
but we don't seem to be using that anymore.
--
Joe Schaefer
Re: Issues with ->pool in CGI environment
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
> [...]
>
>
>>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.
>
>
> But this *is* the env() method, which been around for quite a while now.
Ah, sorry, I wasn't watching the development closely. Just scanning the
commits.
> We just need to document it better.
--
__________________________________________________________________
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
Re: Issues with ->pool in CGI environment
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
>
> 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.
But this *is* the env() method, which been around for quite a while now.
We just need to document it better.
--
Joe Schaefer
Re: Issues with ->pool in CGI environment
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> 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
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
Re: Issues with ->pool in CGI environment
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> 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.
--
Joe Schaefer
Re: Issues with ->pool in CGI environment
Posted by Stas Bekman <st...@stason.org>.
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