perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
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.


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


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


> 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 

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


Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message