On Mon, 7 Aug 2000, ___cliff rayman___ wrote:
> Stas Bekman wrote:
>
> > On Thu, 3 Aug 2000, ___cliff rayman___ wrote:
> >
> > > "Keith G. Murphy" wrote:
> > >
> > > > ___cliff rayman___ wrote:
> > > > >
> > > > > The perl interpreter has a one global symbol table called the
> stash where
> > > > > all global variables are referenced by package and by variable
> name.
> > > > > Since the interpreter does not go away when a script is
> recompiled, neither
> > > > > does the stash or any of the items contained within it. Some
> programmers
> > > > > are probably using this as a feature, and therefore it is
> unlikely that it
> > > > > will change.
> > > > > This is really standard perl stuff and it has nothing to do with
>
> > > > > Apache::Registry in particular. It is just something the
> average perl
> > > > > programmer does not come across since we usually load the
> interpreter, load
> > > > > a program, run the program, exit the interpreter.
> > > > >
> > > > > check out:
> > > > >
> http://thingy.kcilink.com/modperlguide/porting/Global_Variables_Persistence.html
>
> > > > >
> > > > Thanks for the info and the link.
> > > >
> > > > One note though. The info in the link really doesn`t pertain to
> my
> > > > specific question:
> > > >
> > > > "global variables persist inside the same process from request to
> > > > request"
> > > >
> > > > I knew that; I was surprised that they did even on a recompilation
> of
> > > > the script, which the link info doesn`t really refer to.
> > >
> > > i will see if i can find a good place in the guide to add it and
> i`ll send stas the
> > > patch.
> >
> > I`m not sure there is a need for a patch. I think you confuse,
> > something. When the script is recompiled all the variables belonging
> to
> > the package decalared by Apache::Registry or similar are getting
> reset. If
> > you require/use() some modules that declare packages and have global
> > variables -- these won`t be reset unless reloaded or initialized in
> your
> > code.
>
> are u sure about this? not looking to argue with u, just trying to fine
> tune my knowledge of perl and mod_perl in particular.
>
> the following code works similarly to how Apache::Registry loads a sub:
> perl -e '
> $sub=q{package thepkg; use vars qw($thevar); print "evaled sub with
> \$thevar=$thevar\n";};
> package main;
> $thepkg::thevar="first outside value";
> eval $sub || die $@;
> package main;
> print "\$thepkg::thevar=$thepkg::thevar\n";
> $thepkg::thevar="second outside value";
> eval $sub || die $@;
> print "\$thepkg::thevar=$thepkg::thevar\n";
> '
>
> the above code returns:
> evaled sub with $thevar=first outside value
> $thepkg::thevar=first outside value
> evaled sub with $thevar=second outside value
> $thepkg::thevar=second outside value
>
>
> eval $sub does not reinitialize any package vars that i can see
> (although it is late). perhaps Apache::Registry is clearing the global
> vars? i looked at Apache::Registry.pm and did not see anyplace it was
> doing that. there are calls to some C code which did not look like they
> were reinitializing the package vars but the perl internals are beyond
> my comprehension. :-(
>
> stas, if u don't have the tuits to answer - no problem - i know you're
> busy. perhaps someone else knows the answer.
Cliff, I'm not sure what you are trying to show with the above code, what
you should do is to run the script under Apache::DB and see how
Apache::Registry generates the package. See:
http://perl.apache.org/guide/porting.html#The_First_Mystery
Now once this package is built and compiled, *nothing* happens to it --
it's like a loaded from the file module. If you don't initialize vars at
the beginning of your script. And no, Apache::Registry doesn't reset the
global vars. Apache::PerlRun does that.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
