in reply to $SIG{INT} unlink problem

I think the answer by sauoq will most likely be the right one.

I just wanted to chime in with something else. Your code is assuming that fork() always succeeds (a dangerous assumption). Remember that it will return undef upon failure. A failure can be triggered by many events outside of your control, so you should be prepared to deal with them gracefully.

I offer you this substitute code instead:

use strict; use warnings; use constant FORK_WAIT => 2; use constant MAX_ATTEMPTS => 10; our $attempt = 0; my $pid = undef; while (not defined ($pid = fork())) { die "Too many failed fork() attempts: $!\n" if ++$attempt > MAX_ATTEMPTS; warn "fork() failed: $!\n"; sleep $FORK_WAIT; } if ($pid) { # I'm the father } else { # I'm the son }
Hope this helps,

Edit: Thanks to wtp for the correction in the Perl's fork() behavior.

Replies are listed 'Best First'.
Re: Re: $SIG{INT} unlink problem
by wtp (Initiate) on Aug 21, 2002 at 15:51 UTC

    Oh, if only it were so! The Perl version of fork returns undef on failure.

    my $pid;
    
    until ( defined ($pid = fork)) {
    ...
    
Re: Re: $SIG{INT} unlink problem
by agentv (Friar) on Aug 22, 2002 at 02:15 UTC
    When I saw this, I knew that I had seen what ballplayers call "a thing of beauty."
    while (not defined ($pid = fork())) { die "Too many failed fork() attempts: $!\n" if ++$attempt > MAX_ATTEMPTS; warn "fork() failed: $!\n"; sleep $FORK_WAIT; }

    Every artifice that is used here is in its finest form and in proper proportion. And I must know fokat, did your posting originally say that fork() returns -1 on failure? (That is the SVR4 behavior for the system call I believe, and until last week, I had forgotten totally about this as well as the original author of this thread. "Oh," I said, "of course fork can fail! Let's do check for that." While secretly he thinks, Damn, I wonder how much code I should revisit to account for this.)

    ...All the world looks like -well- all the world, when your hammer is Perl.
    ---v