Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
$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.
[...]
So what do we hang the pool on? $bucket?
+1.
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?
It is enough, if you're sticking to the text above.
The pool is going to die at some point; the application (not mp2) has a bug if the bucket is used beyond that point.
Right. Thanks for that idea, Joe.
BTW, I've found a nice way to write tests for this dependency issue (not only this particular method). Instead of trying to hope for a random segfault, I simply create a new pool and use it to create some huge apr table or something and then verify that the object created with the previous temp pool is still valid, if the pool was freed too early, it'll be corrupred, 100% certainly giving either wrong data or segfaults, regardless whether --enable-pool-debug is in effect.
-- __________________________________________________________________ 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]
