timing out slow operations

I'm trying to figure out the code segment on page 417 of the
Camel book, 3/e. It says:

use Fcntl ':flock';
eval {
local $SIG{ALRM} = sub { die "alarm clock restart" };
alarm 10; # schedule alarm in 10 seconds
eval {
flock(FH, LOCK_EX) # a blocking, exclusive lock
or die "can't flock: $!";
};
alarm 0; # cancel the alarm
};
alarm 0; # race condition protection
die if $@ && $@ !~ /alarm clock restart/; # reraise

and then the text says:

The second "alarm 0" is provided in case the signal comes in after
running the flock but before getting to the first "alarm 0".
Without the second alarm, you would risk a tiny race condition ...

This last bit sounds like nonsense to me. If the alarm comes in at
that point, then it comes in, gets processed, and the alarm is turned
off already by that processing -- i.e., by the alarm expiration, not
by an explicit "alarm 0" call. Alarms don't re-start themselves upon
expiration, so there's no need to turn it off again. Am I missing
something?

If there were to be a race condition at all, it would be if you
somehow
managed to escape from the outer eval{} while the alarm had not yet
expired, without turning off the alarm. Then there would be no alarm
handler in place, and your code would die when the alarm finally does
expire. But trying to turn off the alarm outside of the outer eval{}
would still leave a tiny space between the end of that eval{} and the
last
"alarm 0" during which the alarm might come in -- meaning the race is
not solved with this second "alarm 0". But I don't even see any way
out of the outer eval{} that doesn't involve the alarm already being
off, either because of the first "alarm 0" or because the alarm
expired
and therefore got turned off before you executed the first "alarm 0".

.

Relevant Pages

  • Re: (Newbie) Timed operations with eval/die
    ... > I need to do a timed operation: ie give up after some time if it does ... > alarm 10; ## for example ... there is a race condition there. ... I am safe. ...
    (comp.lang.perl.misc)
  • [Q] Rec 16.21: Timing out an op (nested evals)
    ... guard against a race condition: ... alarm 10; ... inner eval loop (including the error generated by the SIGALRM ... In my address everything before the first period is backwards; ...
    (comp.lang.perl.misc)
  • Re: timing out slow operations
    ... alarm 10; # schedule alarm in 10 seconds ... but that is how one makes code bomb-proof: ... expire. ... I suppose you should set up an alarm handler before going into the ...
    (comp.lang.perl.misc)
  • Re: SIGALRM Signal getting lost
    ... > lost. ... I *think* that strictly there is still a race condition even if you call ... alarm as the very last thing in your handler - you just can't guarantee ...
    (comp.sys.hp.hpux)
  • Re: More Help With Siren !!
    ... I do the Bell Test and it Sounds fine and i can make it go off manually but for some reason it wont go ff when the Alarm is tripped. ... Have you allowed the exit delay to expire?? ...
    (alt.security.alarms)