Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
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...
The solution for pools doesn't translate easily into a solution for
other apache objects, because those objects don't have perl ctors
like APR::Pool::new. So deploying something like it for $r and $c would mean putting it into those lightweight wrapper macros like mp_xs_Apache__RequestRec_2obj,
sure, that's doable
which would certainly have a performance impact (especially if you're expecting to add a pool
cleanup there).
The actual cleanup execution shouldn't be the problem, since it'll run after the client has gone away. But registering should be.
Moreover there is a problem of PerlCleanupHandlers themselves, in case they want to have $r available. At the moment there is no way to register some cleanup as REALLY_REALLY_LAST
AFIACT the only other candidate for doing something similar is APR__Brigade.h, but at the moment I still don't see a pressing need for it.
There is no need no, but I think it'd be great to do have it. Why? Because it'd be nice to have idiomatic coding techniques not change after mp2 is released. so people can just copy those snippets and just adjust them to do the real work. So if you want to handle that, that would be great :)
-- __________________________________________________________________ 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]
