but you need to pass pool... so may be not... just another idea to make mod_perl.c less cluttered.
passing the pool isn't that big a deal, or I could just use modperl_global_get_pconf(), in which case I'll also need to use pconf for the logic in modperl_cmd then (instead of parms->pool) so that the table and data have the same lifetime. using the global pool shouldn't be a big deal, since it's not a lot of data (and probably won't be any for 99% of the cases anyway).
Thinking forward I think you want to pass it explicitly from cmd. So if we do that temp pool/sub-pool solution we won't need to remember to change a lot of code and hunt for those global pool uses.
did you have a chance to look at the temp pool? if it does what I think it does (i.e. get destroyed at the end of config) then you could use it instead.
no, I didn't trace the origins of those other two pools. but as per the above assertion, the pools should match, right? in which case it would be difficult to get into the modperl_cmd.c logic.
right, see above.
__________________________________________________________________ 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]
