perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] pool object dependant methods insanity
Date Fri, 24 Dec 2004 18:42:37 GMT
Joe Schaefer wrote:
> Stas Bekman <> writes:
>>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.

So what do we hang the pool on? $bucket? That doesn't sound right, since 
the perl object may go away (thus destroying the pool if noone else 
references it), but the underlying bucket can't see that. so it's probably 
not enough, no? Should we do it anyway?

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message