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

Re: timing out slow operations

Post removed (X-No-Archive: yes)

Re: timing out slow operations

In article <1193646152.551129.42090@t8g2000prg.googlegroups.com>, Glenn
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