perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: removing PerlLoadModule directive handler requirement
Date Thu, 22 May 2003 04:17:05 GMT
Geoffrey Young wrote:
>> Don't you
>> think it's a bad design, if all you want is to trigger the perl 
>> startup early?
> no :)
> because that's not all I want to do.  what I want is to have my code run 
> during the config phase, and that happens to require that Perl be 
> running. see, it's not early if I require it - it's only early if it's 
> started for no reason :)

Basically all you want is for mp2 to behave the same as mp1, i.e. start 
immediately and having PerlModule, PerlRequire do their job right away.

You have found that PerlLoadModule accomplish that, but I urge you to look at 
the code that implements that. You will see that you don't want to run 
PerlLoadModule just to start perl.

>> If perl is not started during the config phase, all directives
>> like PerlModule and PerlRequire are postponed till after the config 
>> phase. If you wish to force those to run immediately during the config 
>> phase, you can turn on the early perl startup using the PerlStartNow 
>> directive.
> the issue is that some modules require activity during startup/config, 
> and thus require Perl to be running.  adding PerlStartNow means that 
> modules cannot rely on only themselves to work - they require even more 
> outside intervention in the form of additional directives to even load 
> properly. yucko.

Good point. So we are falling back to the need to start perl as early as 
possible. But let's not take the goodness of being able to postpone things away.

>> now we just need to implement this simple directive.
> I don't see the reason for this - you can always just insert a no-op 
> within <Perl>.  the effect I want is the ability for module loading to 
> be more DWIMmy.


>> BTW, as I think about it, since the startup file execution is normally 
>> postponed, it's impossible to change the config via $s->add_config. So 
>> this is another case where perl must be started early.
>> Alternatively we can take a more intuitive direction (mp1-like): 
>> always start perl as soon as is loaded. Have a directive 
>> that will try to postpone the startup of perl.
> I don't think we need that either.  it does make some sense to delay 
> perl until it's needed.  it's just that for some things it's needed at 
> config.

But that's what I'm proposing. Let the user decide what they want. For most 
users the default start-perl-immediately will work just fine (and will be 
DWIMish). Others who know that they don't need to start perl early and want to 
make things faster at the startup, will have the tool to make this happen.

So we add:

PerlPostponeStart - use this directive as a very first perl directive in 
httpd.conf if you know that none of the modules that you load needs to be run 
during the configuration phase. This will speedup the startup process.

BTW, Geoff have you seen how long does it take to start threaded mpm mod_perl 
test suite? It's about 30-45 secs on my Dual CPU box. And perl is at fault 
here I think. So if you can shorten this time, it's a good thing. I think this 
has to do with loading DSOs. Once we have a static build we will be able to 
compare more.

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

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

View raw message