|
Posted by nobull@mail.com on January 11, 2006, 10:27 am
Please log in for more thread options
danielmcbrearty@gmail.com wrote:
> Hi perlers,
>
> I'm developing a web based thing with mod_perl and apache. One of the
> things that has bugged me has been running 2 or 3 versions of the site
> (say dev and test), all using a common library "MyLib". The whole thing
> is under version control,
Your problem is fundamental. Under mod_perl the Perl interpreter can
persist from one request to the next. That's like the whole point. If
a module has already been loaded during the processing of request 1 you
don't have to pay the price of loading it again during the handling of
request 2. The flip side of this is that if a module has already been
loaded during the processing of request 1 then request 2 comes along
and sets a different @INC you'll still be using whatever version was
loaded first.
In a development environment you can get over this by limiting each
interpreter to handling a single request - but of course you loose most
of the beniefit of mod_perl.
Alternatively have a separate Apache instance per version.
In mod_perl2 there's apparently a way of defining multiple pools of
Perl servers (and I believe you can set @INC differently in each) and
then assigning those pools to different virtual directories. That way
you could get away with a single Apache. I suspect that if there were
a significant number of versions about this could prove even less
efficient than the one-request-per-interpreter solution.
There may also be solutions using special Apache module like
Apache::StatINC but IMNSHO any solution based on unloading Perl modules
is likely to cause as many problems as it solves. (Note: I'm not saying
Apache::StatINC would be any help at all, I'm saying a similar approach
to that used in Apache::StatINC might be applicable).
> (snip)
> Even though @INC typically includes dot ("."), the current directory,
> this really isn't as useful as you'd think. For one thing, the dot
> entry comes at the end, not the start, so that modules installed in the
> current directory don't suddenly override system versions. You could
> say use lib "." if that's what you really want. More annoyingly, it's
> the current directory of the Perl process, not the directory that the
> script was installed into, which makes it completely unreliable. If you
> create a program plus some modules for that program to use, it will
> work while you're developing, but it won't work when you aren't running
> in the directory the files live in.
> (/snip)
>
> What the hell does THAT mean in teh context of mod_perl?
You probably should never rely on relative paths in @INC when running
mod_perl.
Actually, you probably should never rely on relative paths in @INC when
running perl. That is what the above stanza was trying to convey.
| 
XML Sitemap