Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re^4: Best way to kill a child process

by Eliya (Vicar)
on Sep 21, 2011 at 18:41 UTC ( #927201=note: print w/replies, xml ) Need Help??

in reply to Re^3: Best way to kill a child process
in thread Best way to kill a child process

We both agree on the main issue here: ...

I think we also do agree on the potential side issues related to portability :)

Just for the record: a quick peek into the sources turned up this (in util.c):

#if defined(SA_NOCLDWAIT) && !defined(BSDish) /* See [perl #18849] */ if (signo == SIGCHLD && handler == (Sighandler_t) SIG_IGN) act.sa_flags |= SA_NOCLDWAIT; #endif

and the referenced #18849 is an interesting read.  Essentially, the issue seems to revolve around if and how the sigaction() flag SA_NOCLDWAIT is implemented, i.e. its interactions with the varieties of the wait calls (wait(), wait4(), waitpid() ). And - as I read it - the upshot of it is that if SA_NOCLDWAIT could lead to problems, it isn't needed anyway — which is why the current implemention "mostly" works...

Anyhow, I've used $SIG{CHLD} = 'IGNORE' on quite a few versions and brands of Unix-ish systems (AIX, HP-UX, IRIX, Linux, Solaris) and haven't had any issues with it yet (which is not to say there might not be potential problems on some other platform, of course).

Replies are listed 'Best First'.
Re^5: Best way to kill a child process
by Marshall (Abbot) on Sep 22, 2011 at 00:50 UTC
    I think we also do agree on the potential side issues related to portability :)


    I was thinking about a signal problem that a guy had about 6 months ago related to Apple OS X. We were using C and not Perl.

    Your one line of code will work at least 99% of the time!
    My 2 lines of code may work at a higher probability, but I don't think that it matters at all!

    The "right way" to deal with this is to have a CHLD signal handler. And either set that thing to "IGNORE' or a coderef to a subroutine that causes a waitpid loop. $SIG{CHLD}='IGNORE'; is far superior to doing nothing with the CHLD signal.

      Hi Marshall

      . . . a coderef to a subroutine that causes a waitpid loop. . .

      Just something to think about! I recently (past year) removed all uses of waitpid loops, since on some recent versions of AIX/Unix/Linux, especially on multi-core computers, if the child had been reaped by another core, the SIG handler hanged forever. I replace the code in the parent with:

      if ( kill 0 => $child ) { $children++; ... } else { my $ret = &make_child( ); ... }

      It works, but like you I prefer the sub. I don't know if this behavior is a bug, or it its intentional. The problem doesn't seem to happen it the child exists, only when it has been reaped in a previous call.

      I commented out the previous use, may need it again :-)

      Thank you

      "Well done is better than well said." - Benjamin Franklin

        This is odd and I don't know how to replicate this. If you can replicate this on a Linux system, I'd like to play with it.

        $SIG{CHLD} = sub {while (waitpid(-1, WNOHANG) > 0){} };
        This shouldn't hang if there are no children to reap. And it will reap all available children to reap (0,1,20,150).

        Somewhere in the last couple of threads about this, there was a question about grandchildren. There can be "big trouble in Dodge City" if children are creating grandchildren. Maybe the grandchild dies and expects its parent who was a "child" to reap it, but if that child dies, I suspect that there could be some race conditions about who reaps that - maybe the "step-child" is still running?

        The parent should only be responsible for reaping it own children. I highly recommend against the idea of children making further grandchildren. After a fork(), the child should close the passive socket.

        As a general "rule" children should not spawn more grandchildren. I mean a child is supposed to do its job of talking to a client and then die. But things can get "out of wack" if that child has its own child. So the first "step child" is supposed to die and get reaped, but that can't happen if it itself has as a child that is supposed to be active? I think there is a problem here. We have a "dead" parent, that can't be reaped because it has a child that can't be reaped.

        I think things will be ok if you do not allow children to make other children. First thing that a child should do is close the passive socket.

        First thing that a parent (server) should do after the fork() is close the active socket. Parents (servers) should only listen for new client connections. Children should only deal with their currently active socket (to the client).

        Yes, there are models where parents coordinate children activities, but that is an advanced topic and I don't think that we are talking about that here. That is into the range of not only complicated, but darn complicated!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://927201]
[shmem]: grappa, ginebra o amaretto?
[shmem]: LanX: tried strange stuff wrt autocomplete. No luck :(
[erix]: sambuca
[LanX]: machiato!
shmem fills a glas with sambuca, drops 3 beans of coffee into it, lights the stuff and hands it to erix
[Your Mother]: Liquore Strega. :P
[shmem]: s/beans of coffee/enterprise beans/ :-P
[erix]: Take your bottles -- you're all invited! :)

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (14)
As of 2017-03-28 12:18 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (330 votes). Check out past polls.