Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
But back to my question, what if different pools were used to create different bucket allocations. Scenario:
p_1 => ba_1 => b_1 => bb_1 p_2 => ba_2 => bb_2
now b_1 moves to bb_2, which is coming from a different pool. Don't we have a problem here?
Lets have a look then:
Suppose p_2 has a shorter lifespan then p_1. Then ba_2 dies with p_2, and ba_2's pool cleanup destroys b_1, returning its memory back to ba_1. No problem there.
But if ba_2 and bb_2 both have a longer lifespan then p_1, that may be a problem that setasides cannot fix, because there's no API for altering a bucket's allocator (ie the bucket's list attribute). Usage of b_1 beyond ba_1's lifetime is always invalid.
So in terms of mod_perl apps, buckets and brigades should probably use the allocator with the longest possible lifetime- $c->bucket_alloc.
Yup, that's exactly what bothered me when you've used $bb->bucket_alloc in the examples and that's why I've questioned the idea of having that member exposed in first place (even though it's convenient to use that instead of carrying $c around). Notice that Apache doesn't provide an accessor for it.
p.s. as it seems you've read a lot of the apache code, is it being used at all for that particular reason of not needing to pass bucket_alloc around but get it from the bb?
-- __________________________________________________________________ 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]
