Stas Bekman <[EMAIL PROTECTED]> 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 http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
