perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2] why Apache::PerlSections gets resolved so many times?
Date Sun, 02 Jan 2005 04:21:38 GMT
Philippe M. Chiasson wrote:
> Stas Bekman wrote:
> 
>> Philippe M. Chiasson wrote:
>>
>>> Stas Bekman wrote:
>>>
>>>> Philippe M. Chiasson wrote:
>>>>
>>>>> Stas Bekman wrote:
>>>>> [...]
>>>>>
>>>>> I've traced it down to this line :
>>>>>
>>>>>        handler = modperl_handler_new(p, handler_name);
>>>>>
>>>>> So basically, to be able to use the existing modperl_handler_* 
>>>>> framework to
>>>>> run <perl> sections, I am creating a brand new handler for each

>>>>> section,
>>>>> creating that behaviour.
>>>>
>>>>
>>>> But can you arrange for it not to think that it wasn't resolved yet, 
>>>> keeping things as they are?
>>>
>>>
>>> Not sure I follow you there. In most case, there will be only one 
>>> handler, but
>>> there might be multiple ones, and I'd want to make sure to create one 
>>> and only
>>> one handler for each of them.
>>
>>
>> Only one? That doesn't seem to be the case. It creates a new handler 
>> on every <Perl> section.
> 
> 
> What I am saying is that in most cases, there would only be a need for
> a single handler 'Apache::PerlSections' and it would be invoked once per
> <Perl> sections.

Right.

>> The module Apache::PerlSections is loaded only one, it's the tracing 
>> message that was misleading.
> 
> 
> Not only the tracing message, also the fact that it creates a new 
> modperl_handler_t
> each time around. That's the inneficiency I was refering to.

Agreed.

>>> How do you see that as possible ?
>>
>>
>> I'll fix the tracing. But I've also played a bit to speed things up a 
>> bit and save some memory (see [1]), but I'm not sure whether this is 
>> worth the maintenance overhead.
> 
> 
> Thats definitely a -1 from my point of view. It's duplicating a lot
> of code that should stay in modperl_handler.c

Agreed.

> I believe that the <Perl> sections handler(s) should probably be stashed
> in modperl_config_srv_t->handlers_per_srv just like the other kind of
> handlers and be retrieved with modperl_handler_lookup_handlers().

If you stash it there you can't free it.

Do we support <Perl> sections in vhosts? i.e. is it possible that a 
different perl may need to run it? If not I'd rather see it cached in some 
static pointer and manually freed at the end of config phase.

> IMO, that makes for a much more generic solution, and if there are 50 
> <Perl>
> sections (and a few <Perl> sections with their own custom handlers), there
> would be only a few modperl_handler_t created.
> 
>> In any case, why the handler is not freed when <Perl> section is done?
> 
> 
> That's a certain _leak_ right there.
> 
>> Is parms->pool freed when config phase is over?
> 
> 
> Well, AFAIK, parms->pool is process->pconf, and that doesn't get wiped
> until the process terminates.

So we need to use a temp pool instead.

It's about time we should start thinking about optimizations. I'd check 
other startup thingies that may use the wrong pool which wastes memory at 
run-time.

>> If it is then this effort is certainly moot.
> 
> 
> See above, but I think there is certainly a better solution.
> 
> <Pseudo-code>
> if (!modperl_handler_lookup_handlers()) {
>  modperl_handler_new();
>  modperl_cmd_push_handlers();
> }
> </Pseudo-code>
> 
> I'll submit a patch to illustrate this later on.

gozer++

-- 
__________________________________________________________________
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


Mime
View raw message