powerman has asked for the wisdom of the Perl Monks concerning the following question:

I've found in CookBook recommendation to use two alarm(0) for handling timeouts, i.e instead of simple: 
eval {
  local $SIG{ALRM} = sub {die "alarm here"};
  alarm(5);
  long_code();
  alarm(0);
}

[download]
use more complex: 
eval {
  local $SIG{ALRM} = sub {die "alarm here"};
  alarm(5);
  eval {
    long_code();
  };
  alarm(0);
  # see QUESTION 2 below
}
alarm(0); # see QUESTION 1 below
die if $@ && $@ !~ /alarm here/;

[download]
I 100% agree with need of second internal eval if long_code can call die(). But I also have two questions:
  1. in which case first alarm(0) will not work and we will need to catch this and reset timer with second alarm(0)?
  2. look like there error in CookBook's example because we need to propagate error from internal eval by adding die $@ if $@; where I place comment "QUESTION 2" (maybe this error exists only in russian translation, not sure).
Update: exchanged alarm(0) and #QUES2 lines (just fix a typo).

Replies are listed 'Best First'.
Re: second alarm(0)
by tlm (Prior) on Apr 30, 2005 at 15:26 UTC

    Yep, it sure looks to me like any exceptions raised in the internal eval will go unnoticed. As for the second call to alarm, the authors explain

    The second alarm 0 is in case the signal comes in after running the long-running operation, but before getting to the first alarm 0. If you don't do that, you would risk a tiny race condition—but size doesn't matter in race conditions; they either exist or they don't. And we prefer that they don't.
    The thing is, if the ALRM signal does arrive at that critical juncture the authors describe, what need is there for alarm 0 anymore? The ALRM already went off! The second alarm 0 would be necessary only if perl automatically reset the alarm interval back to its original value (in this case 5) whenever it received an ALRM signal, but this is not the case, at least not in my OS (Linux).

    So I'll go out on a limb here, and have the temerity to correct the venerable TPC by rewriting the recipe's snippet like this: 

    eval {
  local $SIG{ALRM} = sub {die "alarm here"};
  alarm(5);
  eval {
    long_code();
  };
  alarm(0);
  die if $@; # propagate error
}
die if $@ && $@ !~ /alarm here/;

    [download]
    I trust my fellow monks will let me know it if I am wrong.

    BTW, in the English edition of TPC, the alarm interval is set for 10 seconds. I guess Russians are more impatient. :-)

    the lowliest monk

[reply]
[d/l]
      And there another question... If you right about restarting alarm, then proposed second alarm(0) don't fix race condition but make it much more tiny... but size, as mentioned in TPC, doesn't matter when we speak about race conditions. :) 
      eval {
  local $SIG{ALRM} = sub {die "alarm here"};
  alarm(5);
  eval {
    long_code();
  };
  # HERE COME FIRST SIGALRM
  alarm(0);
  die if $@; # propagate error
}
# HERE COME SECOND SIGALRM
alarm(0);
die if $@ && $@ !~ /alarm here/;

      [download]
      On server under high load and alarm(1) instead of alarm(5) there is nothing unusual in my scenario. And second SIGALRM will trigger default handler resulting in killing current process.
[reply]
[d/l]
      I also use Linux. And I forgot about automatical alarm restart feature... I've readed something about this in Stevens'APUE but this was many time ago and I don't have this book now. Can anybody remind me in which cases/OS alarm can be automatically restarted?

      BTW, in the Russian edition of TPC, the alarm interval is set for 10 seconds too. It's just me too impatient to copy example for book as-is. :)

[reply]

        I never heard about an automatic resetting of the alarm interval. I know about a different automatic behavior: Perl will automatically resume some system calls after receiving an ALRM signal; that's why the SIG{ ALRM } handler has to explicitly die. For example, this one-liner hangs: 

        % perl -le '$|=1; $SIG{ALRM} = sub { print q(Goosed!) }; alarm 2; eval
+ { <> }; print q(done)'

        [download]
        because after the ALRM perl goes back to waiting for input. The one-liner also illustrates that the alarm interval is not automatically reset after the program receives an ALRM signal, since the $SIG{ ALRM } handler is called only once.

        the lowliest monk

[reply]
[d/l]

Back to Seekers of Perl Wisdom