André Warnier wrote:
Desilets, Alain wrote:
I'm using mod_perl on Windows 7, and am trying to set things up so
that I can reload my script and all the modules it uses, without
having to restart Apache.
The problem is that my script (called webitext.cgi) updates the @INC
variable using statements like these:
---
use lib "$ENV{WEBITEXT_HOME}";
use lib "$ENV{WEBITEXT_HOME}/bin";
etc...
---
where the value of $ENV{WEBITEXT_HOME} is set differently depending on
the virtual host it's running on. I use this so I can have two
versions of my app on the server, a production and a test version,
each running under a different vhost which defines the env variable
differently (using Apache SetEnv).
The problem is that when Apache::Reload tries to reload the modules,
it does not find them, because it seems to use the value of @INC as it
was BEFORE the script was run (i.e. not including the ones added with
the 'use lib' statements).
This problem occurs whether I use the 'PerlSetVar ReloadTouchFile'
approach or the Apache::StatINC approach. It seems to be a well
documented limitation of Apache::Reload.
So... I thought about setting the @INC path outside of the script. But
I need to do this on a per-vhost basis. According to this page:
http://perl.apache.org/docs/2.0/user/config/config.html#Modifying_C__INC__on_a_Per_VirtualHost
I should be able to do this with something like this:
---
<VirtualHost ...>
ServerName webitextprod
PerlOptions +Parent
PerlSwitches -Idir1 -Idir2 etc...
</VirtualHost>
---
But when I tried this and ran httpd.exe -t -c httpd.conf, it crashed
with the dreaded "free to wrong pool" error:
---
Free to wrong pool 2b60100 not 3d4f10.
---
This error seems to be caused by the PerlOptions +Parent line.
Any suggestion for how to fix or get around this problem would be
greatly appreciated.
Hi.
I do not know much about the "reload" side of things, but something in
the general logic of what you explain above is going against what I know
of the Apache logic.
Contrarily to what you seem to expect above, an Apache "virtual host" is
not a separate process.
Apache starts as a single process, and then it forks "children". Each of
these children is a separate process. But the "virtual host identity"
is something dynamic. Each Apache child can "become" one of the virtual
hosts, at each request. It just "switches personality" depending on
which Host: header is contained in the current request that it processes.
In other words, it does not really make sense to expect a different lib
path per virtual host, since the perl modules and scripts exist on a
"one per process" base, not a "one per virtual host" base.
Or, you have to really set the lib path dynamically, on a per-request
base, not just when your script is first compiled.
Addendum :
I re-read your post, and noticed that you were under Windows. In that case, Apache does
not really "fork children", it runs threads. But the general idea above remains : each
thread will adopt the personality of the virtual host corresponding to the Host: header of
the current request. Things may even be a little bit more confusing; I am not sure, but I
think that if you change the lib path on-the-fly in one thread, it may even affect all
threads currently running.
