in reply to second alarm(0)

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

Replies are listed 'Best First'.
Re^2: second alarm(0)
by powerman (Friar) on Apr 30, 2005 at 15:51 UTC
    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]
Re^2: second alarm(0)
by powerman (Friar) on Apr 30, 2005 at 15:41 UTC
    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]

In Section Seekers of Perl Wisdom