Stas Bekman <[EMAIL PROTECTED]> writes:
Joe, why do we expose $bb->bucket_alloc()?
As I've explained before, the bucket_alloc slot doesn't belong to the brigade, it belongs to some pool. Exposing it is convenient, especially for APR-based libraries which don't care where the bucket allocator
actually comes from.
Good point. I just want those to be documented, so that others don't ask the same question again and again.
(I've also just made it read-only, since you certainly don't want that
to be writable). Doesn't it sort of makes thing dangerous. If let's
say some bucket_alloc was used to create the brigade, then a bucket was allocated using that alloc and then the bucket was
moved to a different brigade, and the first one is destroyed. That's a
potential scenario for a problem.
No it's not. As I explained before, calling apr_brigade_destroy()
on a brigade has no impact on the bucket allocator slot whatsoever. The bucket allocator is only affected by a pool cleanup. Have you
forgotten what I wrote when you asked this question last week, or
do you disagree with my explanation?
Mea Culpa, I've forgotten, my brain is working hard to absorb dozens of french words in Quebecua dressing every day, so I need to write everything down :)
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_2now b_1 moves to bb_2, which is coming from a different pool. Don't we have a problem here?
-- __________________________________________________________________ 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]
