You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/10/05 05:11:33 UTC

$bb->bucket_alloc();

Joe, why do we expose $bb->bucket_alloc()? (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. Why not always just 
use $c->bucket_alloc and just leave the $bb's one alone?

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

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


Re: $bb->bucket_alloc();

Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
> 
> [...]
> 
> 
>>So, based on your experience, should we advise users to use that
>>method just for convenience?. 
> 
> 
> I trust your judgement over my own wrt giving user advice.  I think
> the important thing is that users shouldn't start creating their own
> bucket allocators. Instead they should use one that's already available,
> either from the connection object or from a passed brigade.

Good idea. I'll do that. Thanks for the insights, Joe.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

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


Re: $bb->bucket_alloc();

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:

[...]

> So, based on your experience, should we advise users to use that
> method just for convenience?. 

I trust your judgement over my own wrt giving user advice.  I think
the important thing is that users shouldn't start creating their own
bucket allocators. Instead they should use one that's already available,
either from the connection object or from a passed brigade.

-- 
Joe Schaefer


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


Re: $bb->bucket_alloc();

Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
> 
> [...]
> 
> 
>>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?
> 
> 
> Well it's used a lot in apr_brigade.c, because it makes sense for 
> apr-only apps to do it that way.  In httpd you'll find a few example usages
> in the mod_cache and mod_ssl implementations, which are fairly serious
> modules.

So, based on your experience, should we advise users to use that method 
just for convenience?. Or should we use $c->bucket_alloc or their own 
alloc'ed object in all examples and only in the doc for 
APR::Brigade::bucket_alloc explain that one needs to be careful when using 
  that method, presenting the scenario we discussed in this thread?



-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

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


Re: $bb->bucket_alloc();

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:

[...]

> 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?

Well it's used a lot in apr_brigade.c, because it makes sense for 
apr-only apps to do it that way.  In httpd you'll find a few example usages
in the mod_cache and mod_ssl implementations, which are fairly serious
modules.

-- 
Joe Schaefer


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


Re: $bb->bucket_alloc();

Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

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


Re: $bb->bucket_alloc();

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> 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.

-- 
Joe Schaefer


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


Re: $bb->bucket_alloc();

Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> 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_2

now 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

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


Re: $bb->bucket_alloc();

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> 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.

> (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?

-- 
Joe Schaefer


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