perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [mp2] pool object dependant methods insanity
Date Wed, 22 Dec 2004 04:37:06 GMT
Stas Bekman <stas@stason.org> 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.


-- 
Joe Schaefer


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


Mime
View raw message