Use of goto after an alarm?

[axel]

I am puzzled by the strange action of 'goto' (or lack of action) when
an alarm call is caught.

Code:

======================
print "Ready> ";
local $SIG{ALRM} = sub {
print "Nope\n";
goto LAB1;
print "Nope 2\n";
};
alarm 2;
eval { # XXX
$a = <STDIN>;
}; # XXX
$b = alarm (0);
if ($b > 0) {
print "OK: $b: $a";
} else {
print "Seems to have timed out: $a";
}
exit;

LAB1:
print "\nTimed out\n";
exit;

====================== produces:
Ready> Nope
Seems to have timed out:
======================

Removing the eval statements (marked with comments 'XXX' above),
produces:
======================
Ready> Nope
Can't find label LAB1 at ./q1.pl line 8.
======================

Please no flames about the use of 'goto'... I am just curious as to why
it seems to screw up in these circumstances.

Axel

 

[Toni Erdmann]

I am puzzled by the strange action of 'goto' (or lack of action) when
an alarm call is caught.

Code:

======================
print "Ready> ";
local $SIG{ALRM} = sub {
print "Nope\n";
goto LAB1;
print "Nope 2\n";
};
alarm 2;
eval { # XXX
$a = <STDIN>;
}; # XXX
$b = alarm (0);
if ($b > 0) {
print "OK: $b: $a";
} else {
print "Seems to have timed out: $a";
}
exit;

LAB1:
print "\nTimed out\n";
exit;

====================== produces:
Ready> Nope
Seems to have timed out:
======================

Removing the eval statements (marked with comments 'XXX' above),
produces:
======================
Ready> Nope
Can't find label LAB1 at ./q1.pl line 8.
======================

Please no flames about the use of 'goto'... I am just curious as to why
it seems to screw up in these circumstances.

LAB1 is a label, which is valid inside the "sub{}" only.
You can't 'goto' == exit out of a subroutine.

Toni

 

[Anno Siegel]

[ in reply to a question by (e-mail address removed) about goto]

LAB1 is a label, which is valid inside the "sub{}" only.
You can't 'goto' == exit out of a subroutine.

If you answer questions, please look things up instead of making them up.

From "perldoc -f goto":

.... It can
be used to go almost anywhere else within the
dynamic scope, including out of subroutines...

Anno

 

[axel]

LAB1 is a label, which is valid inside the "sub{}" only.
You can't 'goto' == exit out of a subroutine.

I had wondered about that, althought the Camel book explicitly says that
it is possible to use goto out of a subroutine... and I have tested
it to confirm:

====== code

xx();
print "Goto Failed\n";
exit;

LAB1:
print "'Goto' worked\n";
exit;

sub xx { goto LAB1; }
====== results
'Goto' worked
======

Axel

 

[Toni Erdmann]

I had wondered about that, althought the Camel book explicitly says that
it is possible to use goto out of a subroutine... and I have tested
it to confirm:

====== code

xx();
print "Goto Failed\n";
exit;

LAB1:
print "'Goto' worked\n";
exit;

sub xx { goto LAB1; }
====== results
'Goto' worked
======

Sorry, my fault.

The difference between your first posting and this one here is
that "LAB1:" here is declared/used before sub xx {} is defined.

Maybe this can explain the error?

Toni

 

[Toni Erdmann]

Sorry, my fault.

The difference between your first posting and this one here is
that "LAB1:" here is declared/used before sub xx {} is defined.

Maybe this can explain the error?

No it does not explain the problem. I tried it.

Toni

 

[axel]

The difference between your first posting and this one here is
that "LAB1:" here is declared/used before sub xx {} is defined.

Maybe this can explain the error?

I had thought of that... but that should have be taken care of at
compile time, which it is, just as a subroutine need not be declared in
advance of its being used. The same applies with goto's and labels... no
prior declarations are required... all my experiments have confirmed
that in normal usage no problem arises... except when I try to catch an
alarm signal... I know I must be missing something here, but would be
delighted to know what exactly

Axel

 

[ctcgag]

I had thought of that... but that should have be taken care of at
compile time, which it is, just as a subroutine need not be declared in
advance of its being used. The same applies with goto's and labels... no
prior declarations are required... all my experiments have confirmed
that in normal usage no problem arises... except when I try to catch an
alarm signal... I know I must be missing something here, but would be
delighted to know what exactly

You are missing the fact that signal handlers are weird.
(Sorry, that's the best description I can come up with.)

Apparently, the only way to break free of signal handler is to die out of
it; hopefully to be caught by eval, then after the eval you can check for
the die and goto whereever you want. Not very intellectually satisifying,
I know, but sometimes life is messy.

Xho

 

[axel]

Apparently, the only way to break free of signal handler is to die out of
it; hopefully to be caught by eval, then after the eval you can check for
the die and goto whereever you want. Not very intellectually satisifying,
I know, but sometimes life is messy.

True. The odd thing is that I can call another subroutine, use a
backticks expression to execute an 'ls' for example... do all sorts of
things... except use an internal perl 'goto'!

Axel