On 2011-06-17 05:34, C.DeRykus wrote:
Ruud:
C.DeRykus:
Ruud:
C.DeRykus:

Another solution, not necessarily more elegant, but
more familiar to most  is an eval {} and alarm pair:

EVAL: {
       eval {
            local $SIG{ ALRM } = sub { die "alarm"; };
            local $SIG{ USR1 } = sub { die "usr1" };
            alarm $sleeptime;
            ... some long running operation here ....
            alarm 0;
            1;
        } or do {

Insert:
                my $eval_error = $@ || "Zombie error!";

Huh?   If you insert that statement before doing 'alarm 0',
then, there's a potential have a race condition with the
alarm going off and terminating the entire program with
"alarm clock" before you can even check $@.

Realize that the alarm is then already reset (to the earlier setting)
because the localization gets out of scope.

No, that's not true. The localized signal handler gets
reset but  any alarm that is started in that scope will
still be delivered to the current signal handler unless
turned  off.

Right, but the word "alarm" in my sentence stood for "alarm signal handler", so please re-read.


         eval {  ...  ; "foo" happens and sets $@='bar';
                   ...
                };
                my $eval_error = $@ || "Zombie error!";
                       #  alarm actually does go off now
                       #  and terminates program
                alarm 0;      #  too late
                ....
Therefore you wouldn't want to insert any statement
before turning off the alarm.

Because the alarm signal is localized (to the eval{}), it is not active
in the do{}.

No, it's still active. In the case below, the alarm
that was set inside the scope gets delivered to
the default alarm handler.

And my "alarm signal" was short again for "alarm signal handler".


On freebsd 8.2 for
instance:

$ perl -e 'eval{ local $SIG{ALRM}=sub{die "foo"};
                alarm 1};<>'
Alarm clock: 14

So the alarm that was launched in the eval {} scope
is still active and, even though the localized handler
goes out of scope,  the delivery still occurs later to
the default handler.

Well, I hope I cleared up my bad phrasing. Now best read it again.

--
Ruud

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to