mod_perl: my $var=1 if ...

[Kjetil Skotheim]

I'm having trouble understanding something in mod_perl. The sub handler is:

sub handler
{

...stuff deleted...

my $var=1 if ...condition_A...;
$var=2 if ...condition_B...; if($var){
...someting....
}

}

The IF-block are entered sometimes when both condition_A and B
are false! How can that be? If I do the following instead then
everyting works ok:

my $var; #lexical declaration without if
$var=1 if ...condition_A...;
$var=2 if ...condition_B...;

I suspect that $var is preserved from the previous apache-request
on the same process. Can anyone confirm this?
Should "my $var=... if ..." be totally avoided in mod_perl?

 

[Jay Tilton]

: I'm having trouble understanding something in mod_perl. The sub handler is:
:
: sub handler
: {
: ...stuff deleted...
: my $var=1 if ...condition_A...;
: $var=2 if ...condition_B...; if($var){
: ...someting....
: }
: }
:
: The IF-block are entered sometimes when both condition_A and B
: are false! How can that be?

From the "Private Variables via my()" section of perlsub:

NOTE: The behaviour of a my statement modified with a
statement modifier conditional or loop construct (e.g. my $x
if ...) is undefined. The value of the my variable may be
undef, any previously assigned value, or possibly anything
else. Don't rely on it. Future versions of perl might do
something different from the version of perl you try it out
on. Here be dragons.

: I suspect that $var is preserved from the previous apache-request
: on the same process.

You nailed it.

 

[Kjetil Skotheim]

: I'm having trouble understanding something in mod_perl.
: The sub handler is:
:
: sub handler
: {
: ...stuff deleted...
: my $var=1 if ...condition_A...;
: $var=2 if ...condition_B...; if($var){
: ...someting....
: }
: }
: The IF-block are entered sometimes when both condition_A and B
: are false! How can that be?

From the "Private Variables via my()" section of perlsub:

NOTE: The behaviour of a my statement modified with a statement modifier
conditional or loop construct (e.g. my $x if ...) is undefined. The value
of the my variable may be undef, any previously assigned value, or
possibly anything else. Don't rely on it. Future versions of perl might
do something different from the version of perl you try it out on. Here
be dragons.

(ok, should have RTFM)

: I suspect that $var is preserved from the previous apache-request
: on the same process.

You nailed it.

But it works in "normal perl" outside mod_perl, and its the
same perl-version as compiled into apache. Oh well...I'l just
have to exterminate all those my-if's everywhere.

 

[Keith Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm having trouble understanding something in mod_perl. The sub handler is:

sub handler
{

...stuff deleted...

my $var=1 if ...condition_A...;
$var=2 if ...condition_B...; if($var){
...someting....
}

}

The IF-block are entered sometimes when both condition_A and B
are false! How can that be? If I do the following instead then
everyting works ok:

my $var; #lexical declaration without if
$var=1 if ...condition_A...;
$var=2 if ...condition_B...;

I suspect that $var is preserved from the previous apache-request
on the same process. Can anyone confirm this?

I'm not sure that's what's going on. It would help to know what
condition_A and condition_B were--there are probably variables
surviving in the httpd process that are influencing the conditions
in ways you aren't expecting, thus causing $var to be set. Since
we don't know what your conditions are, though, it's tough to tell.

It would certainly help to post a test case with real code instead
of condition_[AB], and perhaps to check your error_log. If you
find a real problem, I'd also recommend the mod_perl mailing list
(findable from perl.apache.org).

Should "my $var=... if ..." be totally avoided in mod_perl?

I personally don't think it's such a great style, but I don't
know if it's something definitely to be avoided.

- --keith

- --
(e-mail address removed)-francisco.ca.us
(try just my userid to email me)
alt.os.linux.slackware FAQ: http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj8p8RsACgkQhVcNCxZ5ID8WxACeJMM5HxMH+V1GkMeSO0Lql33v
hSAAn3WjaMjs1sgXDXRl+IEKIqCFd6zI
=5phS
-----END PGP SIGNATURE-----