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 Fri, 23 May 2003 05:30:18 GMT
Geoffrey Young wrote:
>  >> 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.
>  >
>  >
>  > Actually it's not fine now. Consider:
>  > PerlRequire /path/to/
>  >
>  > As the current implementation goes we have a problem, because it won't
>  > work unless something (<Perl> or PerlLoadModule) has triggered a perl
>  > startup and the file was actually required during the config
>  > phase.
> oops :)
>  >
>  > So what I'm saying that your issue is not the only one that requires an
>  > early perl startup. So may be the problem is more global and solving it
>  > will automatically resolve your issue, without any heavy patching.
> as I had originally though about it, I figured the issue would only reside
> with modules.  but, as you pointed out, config changes in 
> will have issues too.  hmph.
> personally, I can't see many people using add_config from a - 
> if they can add a they can add the config themselves (except 
> for maybe the tests :).  more typically, I would expect add_config() to 
> be called from modules as to add config settings silently.  
> Apache::WinBitHack is a good example - it overrides XBitHack but (in 
> mp1) still needs to add a PerlFixupHandler to function properly.  in mp2 
> it would just override XBitHack and silently add the fixup handler via 
> add_config().  doug's illustration of using it to add require directives 
> I suspect will also be a common use.

In that case we need to at least fix PerlLoadModule to call ap_add_module only 
if module directives are defined. I still don't like using this interface for 
its side effects.

If we get this functionality in place, we also will need to provide developers 
a hint how to check whether the module wasn't loaded after the config phase. 
Perhaps a simple call to Apache::current_callback will do. Or may be it won't 
help much, as things will fail if not started in time.

> are there other config situations other than add_config() that you can 
> think of?  I still think it's valid to delay interpreter start and have 
> PerlModule behave as it does now (provided we have an alternative :), 
> but as the number of exceptional cases rise, it makes less and less sense.

Nothing comes to my mind but it's possible that there are others, or there 
will be others later on.

BTW, one other reason for postponing startup is to be able to specify 
PerlSwitches anywhere in the config file and PerlInterp* directives as well 
(as Doug has reminded me). Something that won't work after perl was started.

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

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

View raw message