Re: dynamic request hook ordering (take 2)

[Geoffrey Young <ge...@modperlcookbook.org>]

Stas Bekman wrote:
> Geoffrey Young wrote:
> 
>>> Much better, but still why having any data at all in mod_perl.c? Have
>>> the static variable in modperl_apache.c and provide an accessor to do:
>>>
>>> hook_order = apr_table_make(p, 0);
>>>
>>> from modperl_apache.c. Now you are all set.
>>
>>
>>
>> well, I can't see where to draw the pool from or how else to inialize it.
>> that is, unless I just make the declaration
>>
>> static *hook_order = apr_table_make(modperl_global_get_pconf(), 0);
> 
> 
> You could do that. But I was merely suggesting to have a function
> defined in modperl_apache.c that you will call from mod_perl.c, instead
> of accessing the raw variable.

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 :)

> 
> I'm also thinking that we have this and a few other things that are used
> only at the server startup and are no longer needed at run time. So may
> be we should really create a sub-pool and destroy it when we are done
> with it? e.g. create it at the preconfig phase and destroy it at the
> postconfig phase? So we will save a bit of a memory.

yeah, that might be a good idea.

> 
> But that of course can be done separately, after you roll this change in.

ok, cool.  I'll give the logic another once over and commit it tomorrow.

I really, really appreciate the feedback and pointers.  thanks.

--Geoff


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: dynamic request hook ordering (take 2)

[Stas Bekman <st...@stason.org>]

Geoffrey Young wrote:
> 
> Stas Bekman wrote:
> 
>>Geoffrey Young wrote:
>>
>>
>>>>Much better, but still why having any data at all in mod_perl.c? Have
>>>>the static variable in modperl_apache.c and provide an accessor to do:
>>>>
>>>>hook_order = apr_table_make(p, 0);
>>>>
>>>>from modperl_apache.c. Now you are all set.
>>>
>>>
>>>
>>>well, I can't see where to draw the pool from or how else to inialize it.
>>>that is, unless I just make the declaration
>>>
>>>static *hook_order = apr_table_make(modperl_global_get_pconf(), 0);
>>
>>
>>You could do that. But I was merely suggesting to have a function
>>defined in modperl_apache.c that you will call from mod_perl.c, instead
>>of accessing the raw variable.
> 
> 
> 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.

>>I'm also thinking that we have this and a few other things that are used
>>only at the server startup and are no longer needed at run time. So may
>>be we should really create a sub-pool and destroy it when we are done
>>with it? e.g. create it at the preconfig phase and destroy it at the
>>postconfig phase? So we will save a bit of a memory.
> 
> 
> yeah, that might be a good idea.

BTW, what the temp_pool is for? Isn't that exactly the kind of pool that we 
want to use for config only things, that can be nuked when we are done? Does 
it get destroyed after the startup?

>>But that of course can be done separately, after you roll this change in.
> 
> 
> ok, cool.  I'll give the logic another once over and commit it tomorrow.

So you'd be the first one to commit in Spring ;) Unless gozer beats you with 
his static modperl build ;)

> I really, really appreciate the feedback and pointers.  thanks.

;)

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org