Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
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?
IMO they should probably be replaced with $bb->cleanup.
In which case there is no need to invoke new() inside the loop.
I suppose in some cases someone may still want to explicitly call destroy to save memory, if they do a lot of allocations in a tight loop (but as you say below it doesn't make any difference at the moment compared to $bb->cleanup)
Actually invoking $bb->destroy is almost always a mistake right now (even though win32 reportedly has problems with that)...
Precisely, we can't use it until we figure out what the problem is.
[...]
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?
Not quite. Right now all $bb->destroy does is run the pool cleanup that
destroys its buckets, and then removes that pool cleanup. At one point
the idea of allocating the brigade struct from the bucket allocator was tossed around, which would have made $bb->destroy wipe out the brigade struct as well (thus invalidating the C pointer). That change hasn't happened, yet, so the brigade struct is allocated from the pool.
OK, I wasn't aware of that, assuming that the docs are not declaring something that the code doesn't do.
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.
That would be a nice thing to do.
I think we shouldn't bother loging it in todo lists, since I'm pretty sure joes will post a patch in just a few minutes :)
Seriously, if we could abstract the magic you've added to the pool code to be more general purpose (sans adding overhead by generalization) it'd be nice to deploy it for $r, $c and may be other objects...
-- __________________________________________________________________ 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]
