Geoffrey Young wrote on 4/27/04, 1:56 PM: > > > The main rationale I think is because of the restart, loading is twice > > as slow. So the more things you can postpone until after restart the > > faster your server will start. > > I suppose that's a consideration. but I hate to not have > functionality just > because it takes the server a while to start. for most production > environments, which are behind some kind of load-balancer, a slow > start or > restart really doesn't matter. large, complex applications already > can take > minutes to start.
I can see how startup time (or restart time) could be important in many situations. However, when running "apachectl configtest", aren't you running a new httpd process, separate from the real server? In that case startup time should not be critical - why not load the interpreter? When doing a real server start (or restart), the code gets executed as expected (without using the <Perl></Perl> force trigger), so when the interpreter is loaded isn't an issue (as far as my original problem is concerned). It is only with "configtest" do I see this behavior. Is it that mod_perl cannot easily distinguish between a "normal" start and a "test" start?
Please take a look at my reply to Geoff, the startup time is not the only reason. A more significant reason is that PerlSwitches must be set before perl starts. If you want to set PerlSwitches inside vhosts, and perl has already been started, you are out of luck. Here is why you want this feature:
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlSwitches_ http://perl.apache.org/docs/2.0/user/config/config.html#C_Clone_ http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_
With a <perl> hack section, or a new directive to do just that - force the startup of the interpreter, you have a complete control over things. If we start early by default, then you're out of control.
__________________________________________________________________ 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
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html