Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41C8FDAF.3000805@stason.org>
Date: Tue, 21 Dec 2004 23:53:03 -0500
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
MIME-Version: 1.0
To: Joe Schaefer <joe+gmane@sunstarsys.com>
Cc: dev@perl.apache.org
Subject: Re: [mp2] pool object dependant methods insanity
References: <41C4640A.4030701@stason.org> <41C8D0CE.30704@stason.org>
 <87hdmfghmp.fsf@gemini.sunstarsys.com> <41C8E581.1070603@stason.org>
 <87acs7gd8t.fsf@gemini.sunstarsys.com>
In-Reply-To: <87acs7gd8t.fsf@gemini.sunstarsys.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Joe Schaefer wrote:

>>>     $bucket->setaside($pool);
>>>that means "this bucket may need to live as long as this pool does".
>>>If we change the semantics to "this pool needs to live as long as
>>>this bucket does", IMO we've made a mistake. If you agree, then I
>>>think mpxs_APR__Bucket_setaside can be removed from the list.
>>
>>I haven't analized the actual methods yet, other than checking that
>>they return an object.
>>
>>I agree that this is a tricky issue with this method. But if you don't
>>tie the pool along with the setaside data, how is it going to be
>>preserved if the pool will be gone? the setaside data will become
>>corrupted, no? 
> 
> 
> Sure, that could happen.  Thinking about it a bit more, perhaps your
> first guess is right.  Restating the semantics with a cleaner 
> separation of (Perl) variable from (C) value:
> 
>         $bucket->setaside($pool) means 
> 
>   the apr_bucket_t attached to this APR::Bucket object needs to 
>   survive as long as the underlying apr_pool_t.  However, if
>   that apr_pool_t is owned by some APR::Pool object, that object
>   should [*] survive at least as long as the APR::Bucket object does.
> 
> Agreed?  If so, then setaside() does belong on the list.
> 
> [*] - "should", not "must", because people can always explicitly 
> destroy the pool.

+1


-- 
__________________________________________________________________
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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org