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...
> 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,
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.
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. 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.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
