> Actually, you don't even need modperl_apache_init_hook_order(), just
> move that init code into: modperl_apache_get_hook_order();
>
> void modperl_apache_get_hook_order(apr_pool_t *p) {
> if (!hook_order) {
> hook_order = apr_table_make(p, 0);
> }
> return hook_order;
> }
I had suggested that before:
>> yeah, ok. so I can keep the init in pre-config? I guess if I use the
>> pconf
>> it doesn't really matter - I can have the accessor init using pconf if
>> the
>> table is NULL. and I was doubting the lifetime of parms->pool anyway :)
>
>
> If we implement the sub-pool for temp uses, then it'll have to be in
> pre-config, so keep it there.
>
> 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).
>
> 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.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
