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:[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]
