On Jun 16, 1:54 am, rvtol+use...@isolution.nl ("Dr.Ruud") wrote:
> On 2011-06-15 14:18, C.DeRykus wrote:
>
> > [...] mixing
> > alarm/sleep is a bad idea. See: perldoc -f alarm.
>
> > Another solution, not necessarily more elegant, but
> > more familiar to most is an eval {} and alarm pair:
>
> > EVAL: {
> > eval {
> > local $SIG{ ALRM } = sub { die "alarm"; };
> > local $SIG{ USR1 } = sub { die "usr1" };
> > alarm $sleeptime;
> > ... some long running operation here ....
> > alarm 0;
> > 1;
> > } or do {
>
> Insert:
> my $eval_error = $@ || "Zombie error!";
Huh? If you insert that statement before doing 'alarm 0',
then, there's a potential have a race condition with the
alarm going off and terminating the entire program with
"alarm clock" before you can even check $@.
eval { ... ; "foo" happens and sets $@='bar';
...
};
my $eval_error = $@ || "Zombie error!";
# alarm actually does go off now
# and terminates program
alarm 0; # too late
....
Therefore you wouldn't want to insert any statement
before turning off the alarm. Particularly if the
alarm handler is localized to the eval{} which is the
best idion.
>
> and use $eval_error in the code below.
>
> > alarm 0;
> > if ( $@ =~ /alarm/) { warn "expired..." }
> > } elsif ( $@ =~ /usr1/) { redo EVAL; }
> > } elsif ($@) { die "unexpected error: $@"; }
> > }
> > }
>
> Realize that $@ is a global variable, so can get changed at a distance.
Yes, but $@ was just set and the immediate danger is
an alarm race condition that needs to be addressed
first. The eval {} was just exited after all and nothing
intervenes except the $@ condition if-elsif clauses
that needed to protected from an uncaught alarm.
>
> The last 'elsif' was particularly wrong: it would not die if $@ is
> false. Just make it an 'else'.
>
But what kind of scenario would do that....? If there's
an uncaught signal for instance, the program will
still terminate immediately with an "alarm clock".
Or if the program unexpectedly exits in some benign
way inside the eval {}, you'd never see that final 'else'
clause anyway. If the final statement '1' in the eval {}
gets short-circuited somehow, I'd think all bets are off.
--
Charles DeRykus
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
