Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
I like the idea of bb, but you will need to explicitly destroy it as well...
Not sure I believe that...
You mean all the calls to $bb->destroy are useless and even wrong?
Someone has raised this point before, bb's should have a DESTROY
method, it was trivial to add, but as soon as I did that, things
started to crash, because of the bb's passed as an argument to input
filters are special and can't be destoyed at the end of handler's
scope (since the upstream filter won't see anything then). So if we
code the filter handlers code to mark those bb's as special (so that
they don't get destroyed at the end of the scope) then we can have the default APR::Brigade::DESTROY run automatically.
I don't see the point of an APR::Brigade::DESTROY. What users need to know about brigades is
1) if they invoke $bb->destroy themselves, they become responsible for cleaning up any future buckets added to that brigade,
Ah, shouldn't that be $bb->cleanup? If you destroy $bb, how can you add any new buckets to it?
2) if they feed a brigade to ap_pass_brigade, according to the ap_pass_brigade docs, they should not touch that brigade object
ever again. Even calling destroy() isn't documented as being safe.
yes, that's certain.
Trying to simplify some of this mess for modperl filter authors, perhaps with a smart DESTROY sub, will add lots of complexity to APR__Brigade.h - similar to what's in APR__Pool.h now.
That's exactly what I was thinking about. Though I can see other applications for your recent work on APR::Pool. For example we need this kind of protection for $r and other major objects. If people get $r into a closure, they have a guaranteed segfault on the next request, which is usually very hard to trace. The SVMAGIC protection will allow us to croak when someone writes a closure instead of segfault.
I'm not sure it would be worthwhile to do that and risk introducing new bugs into the filter system. Also it's quite possible that [EMAIL PROTECTED] will change its collective mind again about the correctness of (2), so things may get even messier if 2.0 and 2.2 have different ap_pass_brigade semantics.
Heh, who knows, by the time we get mp2.0 out, if Apache 2.2 is released, we may just as well just go with 2.2 and drop 2.0 altogether :)
-- __________________________________________________________________ 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]
