unsubscribe remove

2001-05-29 Thread Warren D. Johnson

unsubscribe remove




Global Variables Question

2001-04-25 Thread Warren D. Johnson

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

2000-09-04 Thread Warren D. Johnson


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

2000-09-03 Thread Warren D. Johnson

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?