perlknight has asked for the wisdom of the Perl Monks concerning the following question:

All, could someone shed some light on this code snippet from "Network Programming With Perl", this snippet is from page 447, preforking using share mem:
sub do_child {
   ...
   $SIG{HUP} = sub { $done++; };
   while { !$done && $cycle--) {
      $status{$$} = 'idle'; kill ALRM=>getppid();
      my $c;
      next unless eval {
          local $SIG{HUP} = sub { $done++; die};
          ...
      }
      ....
    }
}

[download]
Shouldn't one SIGHUP be enough to terminate the child processe? Why do you need two SIGHUP? Thanks.

Replies are listed 'Best First'.
Re: Preforking using share mem
by Ionitor (Scribe) on Jul 24, 2002 at 16:55 UTC
    This is a classic case of dealing with signals in eval. This code is dealing with a SIGHUP being sent at any time which will terminate the loop (not to terminate the child process). If SIGHUP is sent during the loop, but not during the eval, then the first handler will handle the signal and set $done to 1.

    However, if a SIGHUP was sent during the eval without the second signal handler, the SIGHUP would not cause the eval to die, which presumably would cause some problem.

    I'm not sure this is a very good way of coding this. There appears to be a race condition, where if the signal is received at the beginning of the eval before the first line of code, the new signal handler is never used. I'd have to see the rest of the code and freshen myself on signal handling to know how to improve the code to avoid the race condition.

[reply]
[d/l]
[select]
Re: Preforking using share mem
by Abigail-II (Bishop) on Jul 24, 2002 at 16:29 UTC
    The code fragment doesn't actually send any HUP signal. It does install two (different) SIGHUP handlers though.

    I'm afraid I don't understand your question.

    Abigail

[reply]
      I think he is asking why the second SIGHUP handler is installed at all. Shouldn't the first one handle all cases, especially since the localized one is identical to the inherited one. I can understand if you got to a point where you wanted to assign different behavior in the second handler, but in the above case it doesn't really make sense to me either.

      Do you know what might be happening here Abigail-II?

      "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!
[reply]
        I dunno about you, but in my Perl die is not a no-op.

        As I said, the installed handlers are _different_. The second one dies, the first one doesn't. The dying one is inside an eval. Hmmmm, smells like an exception handling.

        Abigail

[reply]
[d/l]

Back to Seekers of Perl Wisdom