Re: timing out slow operations
- From: Jim Gibson <jgibson@xxxxxxxxxxxxxxxxx>
- Date: Mon, 29 Oct 2007 10:21:49 -0700
In article <1193646152.551129.42090@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, Glenn
<eponymousalias@xxxxxxxxx> wrote:
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?
I believe the issue is a potential signal that is not the alarm signal
occurring after the inner eval but before the subsequent alarm 0. It
seems unlikely, but that is how one makes code bomb-proof: expect the
improbable and deal with it. After all, it doesn't hurt much to do an
extra alarm 0.
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".
I suppose you should set up an alarm handler before going into the
outer eval.
--
Jim Gibson
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
.
- References:
- timing out slow operations
- From: Glenn
- timing out slow operations
- Prev by Date: Re: PID of exec
- Next by Date: Regex Help
- Previous by thread: timing out slow operations
- Next by thread: how to close a stalled file descriptor?
- Index(es):
Relevant Pages
|
