G
Glenn
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".
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".