httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: Issues with ->pool in CGI environment
Date Sun, 25 Jul 2004 18:37:14 GMT
Stas Bekman <stas@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


Mime
View raw message