SPUG: Apache and Modules
cmeyer at helvella.org
Wed Jan 23 13:32:46 CST 2002
On Wed, Jan 23, 2002 at 09:33:17AM -0800, Peter Darley wrote:
> My question is thus: In order to more fully understand the inner
> workings of the system, can someone describe the rules Apache uses for
> caching modules? Does the behavior that I described make sense, or do
> y'all think I'm missing something?
When running code in the mod_perl framework, the rules for how Perl
loads and uses modules are basically the same as non-mod_perl. You need
to keep two things in mind: apache runs one parent process that forks
off children to do the work. Each "individual" script becomes a
subroutine in the same large mod_perl environment. Thus script_a and
script_b share any modules that are loaded before the fork. Modules
loaded after forking are limited to just that particular process. Apache
child processes typically have a limited lifetime.
You can examine %INC to see which modules are loaded, and where on disk
they were loaded from. For example, try:
perl -MData::Dumper -le 'print Dumper \%INC
then try dumping it from within a mod_perl program
There are two common ways to load up a module before the fork. The first
is with a 'PerlModule' directive in your apache config file. Alternatively
you can use a 'PerlRequire' directive, and point it at a Perl script in
which you can do some setup (adjust @INC, load up shared data ...) and
> Peter Darley
> P.S. I understand that having packages of the same name in different places
> is probably not good, and I'll clean it up in the future, but because of
> time considerations I don't have a whole lot of choice for now.
Not only not good, but, depending on your situation, just plain won't work.
Scripts running in the mod_perl framework are not 'standalone scripts', but
rather are translated on-the-fly into subroutines that are called from within
the same environment. Thus if script_a.pl loads up a 'config' module by
use lib '/script_a/private/libdir';
and script_b tries something similar:
use lib '/script_b/private/libdir';
The results will be unpredictable. If they happen to be called from two
different apache child processes, then everything will appear to work fine.
If they happen to be called sequentially from the same apache child, then
script_b could get script_a's Config module, or vice versa.
A super ugly kludge could be:
use lib '/my/own/private/idaho';
require Config; Config::import;
Much better to rename the modules to Script_a::Config or something unique.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
For daily traffic, use spug-list for LIST ; for weekly, spug-list-digest
Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/
More information about the spug-list