Preforking using share mem

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.

Comment on Preforking using share mem Download Code

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]
Re: Re: Preforking using share mem by Rex(Wrecks) (Curate) on Jul 24, 2002 at 16:47 UTC
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]
Re: Preforking using share mem by Abigail-II (Bishop) on Jul 24, 2002 at 16:56 UTC
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]
Re: Re: Preforking using share mem by Rex(Wrecks) (Curate) on Jul 24, 2002 at 17:53 UTC


Perl: the Markov chain saw
	PerlMonks