unsubscribe remove
unsubscribe remove
Global Variables Question
Hello All, I apologize if this is in a FAQ somewhere. I have a script, lets call it test.pl. Test.pl requires in config.pl. Test.pl uses variables (via use vars) from config.pl. These variables are defined and given values in config.pl. AFter the first usage of test.pl, the variables we are pulling in from config.pl no longer have values. So it's something like this: config.pl use vars ($G_ROOTPATH); $G_ROOTPATH = /home/warren; config.pl test.pl require config.pl; use vars ($G_ROOTPATH); # at this point, G_ROOTPATH is inherited from config.pl and has the value of /home/warren test.pl On the first run of the script G_ROOTPATH in test.pl has the value of home/warren... subsequent runs, it does not. I'm a little confused as to exact ways modperl handles global variables. Anyone have a simple tweak for this? Or do I have to make a config package? Thanks in advance!
Re: StatINC Question
Matt, Thank you for the followup. My original thought was that StatINC reloaded modules as appropriate and that each child should share a common cache of pre-compiled scripts. Since that is not the case, it makes developing larger applications in mod_perl a bit trickier. Trickier because now everytime I modify some file that falls under the supervision of StatINC I have to do a graceful restart to get all the scripts re-synchronized/recompiled/reloaded. Is there any other way around this? Can you force the apache's child processes to all use the same cache ? I've resorted to using PerlRun until it's time to go production, then i will switch to full modperl. Hm, thanks! -Warren [SNIP, SNIP, SNIP] received a request to handle a mod-perl-script that StatINC would tell the server to hold up for a second while it recompiles these modules and then let it go on it's way. It's almost as if each child process maintains it's own seperate cached version of the modperl-covered scripts. Is this the case? Yes, this is the case. Each child has its own copy of the compiled module. When you initially start the server, if your modules are pre-loaded, initially this memory will be copy-on-write shared across each child (i.e. only one area of memory used and shared between the children), but when you reload them using something like StatINC, that sharing disappears. You could try PerlFreshRestart and issue a graceful restart if this isn't
StatINC Question
Regards all, I've installed mod_perl and latest version of apache. Everything seems to be working fine. I have set StatINC as the PerlInitHandler in my httpd.conf so as to stat() file and libraries which are are dependencies of scripts handled by the modperl handler. In addition, I have a startup file which is run early on in my .conf to add another lib to the @inc (or is it %INC?) variable so StatINC will check in the necessary directories. Here is my problem: StatINC seems to work fine several times after I restart the server but then at some point begins to act funky. I'll reload a page and either/or a source file will get reloaded every time (despite it's time not changing) or i'll get different versions of the page popping up (versions which existed in previous revision of my source file). Its from looking at my error_log that different httpd child processes are catching the different browser requests and reloading the source files. It is extremely frustrating to say the least as I can't understand what the problem really is. Logic would dictate that if a httpd child process received a request to handle a mod-perl-script that StatINC would tell the server to hold up for a second while it recompiles these modules and then let it go on it's way. It's almost as if each child process maintains it's own seperate cached version of the modperl-covered scripts. Is this the case? Does anyone have any ideas?