perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: removing PerlLoadModule directive handler requirement
Date Thu, 22 May 2003 04:37:46 GMT

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

not exactly.  I think it's fine in most cases to have PerlModule behave as 
it does now.  it's in the exceptional cases that the problem resides.

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

the idea for PerlLoadModule was born out of necessity - PerlModule was 
insufficient for directive handlers because directive handlers need to run 
perl at config.  so the problem isn't with PerlLoadModule, but rather it's 
implementation.  I think it should me made more generic and not just apply 
to directive handlers because there are other things modules might need to 
happen at config time.

but yes, currently there is more to PerlLoadModule than I require.  but I 
think that probably can be abstracted away somewhat so that PerlLoadModule 
be made generic and directive handlers still require PerlLoadModule.  it is 
a lot of work, though :)

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

the need is isolated.

in mp1 directive handlers require PerlModule - use() from is 
insufficient, even though it suffices for loading most other modules.  I'm 
suggesting that we follow that same pattern with PerlLoadModule - in some 
cases (which module authors will know and decide) activity will need to 
happen at config time, for the majority of others it will be sufficient to 
use PerlModule.

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

actually, it's the module author I'm concerned with, not the user.  "by the 
way, if you want this module to work you'll need to start perl early" 
doesn't make much sense to users, and I still think early is a misnomer. 
the better way (I'm convinced) is to abstract away the notion of the 
interpreter and say to module authors "if you require LoadModule behavior, 
such as per-module initializations that need to occur during configuration, 
use require PerlLoadModule.  if you can live with your module being loaded 
on demand, suggest PerlModule instead"

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

this makes the issue more about tweaking the server than it addresses the 
needs of individual modules.

anyway, this is probably something else for us to discuss at OSCon.  I doubt 
I'll be able to do anything here but complain over the next few months.

> BTW, Geoff have you seen how long does it take to start threaded mpm 
> mod_perl test suite? 

everything on my P233 is slow :)

anyway, time for sleep.


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

View raw message