Re: Package Lexicals and PerlModule
mgraham ([EMAIL PROTECTED]) said something to this effect:
With the above I expect to be able to call the following in some
handler:
Foo::load_var()
...and $PACKAGE_LEXICAL should still be 'wubba'.
...Except that by calling Foo:load_var() you are setting $PACKAGE_LEXICAL
to undef (by passing in an empty list via ()), rather than retrieving it.
You should do something like:
package Foo;
{ # Block scope this stuff just to ensure that no other subroutine besides
# var can modify $PACKAGE_LEXICAL.
my $PACKAGE_LEXICAL;
sub var {
return
(@_)
? $PACKAGE_LEXICAL = shift
: $PACKAGE_LEXICAL;
}
}
# More of package Foo here...
1;
This will set $PACKAGE_LEXICAL if you pass something in, and return it, or
just return it otherwise. Each child will have its own $PACKAGE_LEXICAL.
(darren)
--
All things are possible, except for skiing through a revolving door.
RE: Package Lexicals and PerlModule
darren chamberlain wrote:
...Except that by calling Foo:load_var() you are setting
$PACKAGE_LEXICAL
to undef (by passing in an empty list via ()), rather than
retrieving it.
Well, actually, I was checking to see if it was set first:
sub load_var {
my $param = shift;
$PACKAGE_LEXICAL = $param if $param;
}
Your example does essentially the same thing, but is interesting
because it puts the sub and the lexical variable in a nested block
scope, and as you say:
Each child will have its own $PACKAGE_LEXICAL.
That's a neat trick! However, for my purposes, I don't want each
child to have a separate $PACKAGE_LEXICAL. I want to set the variable
with the parent process (actually from setup.pl) and I want children
to be able to call the sub without any parameters. And I want the
variable to be visible to subs in the same package, but not to code
outside the package. It's kind of like a class variable without
objects. Maybe it would be clearer with two subs:
package Foo;
my $PACKAGE_LEXICAL;
sub set_var {
$PACKAGE_LEXICAL = shift;
}
sub do_stuff {
# do something with $PACKAGE_LEXICAL;
}
I want to be able to call Foo::set_var('wubba') from startup.pl, and
then call Foo::do_stuff() from some child process.
The weird thing is, this works as I expect when I put "PerlModule Foo"
in httpd.conf, but not when I put "use Foo;" in startup.pl.
Does everybody else use PerlModule to pull in their modules, or
startup.pl?
Michael
Re: Package Lexicals and PerlModule
On Fri, 4 Aug 2000, darren chamberlain wrote: Sharing a variable among children is difficult; you need to use IPC::Sharable or something similar. Not if it's read-only after the fork, which this one appears to be. You can load it with a value at startup and it will be shared. - Perrin
Re: Package Lexicals and PerlModule
On Sun, 30 Jul 2000, mgraham wrote: Under mod_perl, I find inconsistent behaviour. It works fine when a module is loaded via the PerlModule directive in httpd.conf. However when a module is loaded via startup.pl, the package lexicals "forget" their values between calls. [...] The strange thing is that this works when Foo is required in httpd.conf via a "PerlModule Foo" directive. But when Foo is pulled in via a "use Foo" in startup.pl, $PACKAGE_LEXICAL does not keep it's value. This sounds like a bad interaction with PerlFreshRestart and closure variables. Does it work if you turn off PerlFreshRestart? Can you live with that? By the way, PerlFreshRestart is not supposed to be on by default, but using mod_perl compiled as DSO causes similar behavior in recent versions (1.22 on). - Perrin
RE: Package Lexicals and PerlModule
Perrin Harkins wrote: This sounds like a bad interaction with PerlFreshRestart and closure variables. Does it work if you turn off PerlFreshRestart? Can you live with that? Yes! It works with PerlFreshRestart Off. I think you're right - it probably has something to do with the timing of when various bits get compiled and executed. By the way, PerlFreshRestart is not supposed to be on by default, but using mod_perl compiled as DSO causes similar behavior in recent versions (1.22 on). I had it turned on for some reason. Why should PerlFreshRestart be on, anyway? Ostensibly, it's so you can make sure that your modules can survive a soft restart, but can't you also gather that from 'apachectl graceful'? Michael
RE: Package Lexicals and PerlModule
On Fri, 4 Aug 2000, mgraham wrote: Why should PerlFreshRestart be on, anyway? Ostensibly, it's so you can make sure that your modules can survive a soft restart, but can't you also gather that from 'apachectl graceful'? With PerlFreshRestart turned off, a graceful restart will not reload changed code. You have to do a full stop/start to pick up changes. - Perrin
RE: Package Lexicals and PerlModule
"PH" == Perrin Harkins [EMAIL PROTECTED] writes: PH On Fri, 4 Aug 2000, mgraham wrote: Why should PerlFreshRestart be on, anyway? Ostensibly, it's so you can make sure that your modules can survive a soft restart, but can't you also gather that from 'apachectl graceful'? PH With PerlFreshRestart turned off, a graceful restart will not reload PH changed code. You have to do a full stop/start to pick up changes. Unless you are using mod_perl as a DSO in which case PerlFreshRestart is irrelevent -- it is always freshly started. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: Package Lexicals and PerlModule
On Sun, 30 Jul 2000, mgraham wrote: Normally, I expect that lexical 'my' vars declared at the package scope (i.e. at the top of a file), should be visible to subroutines declared in the same package, and should maintain their values between calls to those subroutines. If you are running perl v5.6 or later, I think you can use "our" instead of "my" and it will do what you want it to do. As for why it acts this way, I'm not sure...perhaps someone else on this mailing list can shed some light on this issue. -Philip Mak ([EMAIL PROTECTED])
