in reply to Re: Re: multiple fork()
in thread multiple fork()

Don't catch $SIG{CHLD} as each catch gives your program about a 1% chance of die'ing since Perl's signal handlers aren't safe. See "perldoc -f waitpid" for how to reap children without catching signals.

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: multiple fork()
by Dominus (Parson) on Apr 17, 2001 at 03:55 UTC
    Says tye:
    each catch gives your program about a 1% chance of die'ing
    Is that number "1%" actually based in reality, or did you just make it up out of your head?

    Happy Bicycle Day!

    --
    Mark Dominus
    Perl Paraphernalia

[reply]

      Both? It is from a vague memory of someone (Ilya?) running some tests before we realized why signal handlers weren't reliable. He found that the rate of failure for signal handlers was constant whether they did nothing or something.

      I don't have time to at the moment, but a search of Usenet might turn up the original research results.

      The start of this part of the thread makes me wonder if there is some operating system dependency that I don't understand or recent patches to improve the problem.

              - tye (but my friends call me "Tye")
[reply]
Re: (tye)Re: multiple fork()
by Rhandom (Curate) on Apr 17, 2001 at 00:29 UTC
    My bad. Catch may have been misleading. I generally do things like 
    use POSIX ();
$SIG{CHLD} = \&sig_chld;
sub sig_chld {
  1 while (waitpid(-1, POSIX::WNOHANG()) > 0);
  $SIG{CHLD} = \&sig_chld;
}

    [download]
    In my terminology, this is catching the SIG CHLD. I haven't had any trouble with this sort of setup under some extremely heavy loads.
[reply]
[d/l]

      Then you have been lucky. It can fail.

              - tye (but my friends call me "Tye")
[reply]
        What os/systems have you had trouble on. I got my example from perlipc. There is a note in there which says:
        "But that will be problematic for the more complicated handlers that need to reinstall themselves. Because Perl's signal mechanism is currently based on the signal(3) function from the C library, you may sometimes be so misfortunate as to run on systems where that function is "broken", that is, it behaves in the old unreliable SysV way rather than the newer, more reasonable BSD and POSIX fashion. So you'll see defensive people writing signal handlers like this:"
        and then an example similar to mine follows. I have found it to be very stable under a 2.2.16 linux kernel. Maybe other os's have gaping holes in them, but the linux distros I have tried it on are fine.
[reply]
[d/l]

In Section Seekers of Perl Wisdom