Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <4103DC74.6000907@stason.org>
Date: Sun, 25 Jul 2004 09:14:44 -0700
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040708
MIME-Version: 1.0
To: Joe Schaefer <joe+gmane@sunstarsys.com>
Cc: apreq-dev@httpd.apache.org
Subject: Re: Issues with ->pool in CGI environment
References: <877jst4470.fsf@gemini.sunstarsys.com>
In-Reply-To: <877jst4470.fsf@gemini.sunstarsys.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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