Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^3: Best way to kill a child process

by Marshall (Prior)
on Sep 21, 2011 at 15:31 UTC ( #927156=note: print w/ replies, xml ) Need Help??


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

Good point about POSIX. My Perl servers usually have:

use IO::Socket; use POSIX ":sys_wait_h";
Yes, on some platforms, setting up the sigaction stuff to a NULL handler will cause an "auto reap", but AFAIK that is not universal - I'm thinking about the low level C calls that Perl would use. In this case, this is an issue of how the OS deals with sigaction() handlers, not how Perl itself works. Perl cannot do what C cannot do.

I guess where I'm at is that the code I suggested is going to work on all platforms all the time (AFIK). I agree that 'IGNORE' will work on almost all platforms. I'm just not sure about the difference between "almost all" and "all". This detail probably doesn't matter for this app - it doesn't sound like a "general purpose" application as far as the OP is concerned.

So YMMV. Setting "IGNORE" is not "wrong" and it is "easier".

We both agree on the main issue here:
that the right way to deal with this is to explicitly do something with the CHLD signal: either a) explicitly ignore it which hopefully will cause the OS to "autoreap" the child or b)set a simple subroutine like I suggested. As long as one of these options "works", then it will work in all cases of child death: a) if the child kills itself (maybe a via a die statement) or b)I kill my own child or c)somebody else kills it.


Comment on Re^3: Best way to kill a child process
Download Code
Re^4: Best way to kill a child process
by Eliya (Vicar) on Sep 21, 2011 at 18:41 UTC
    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).

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

      Yes.

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://927156]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (9)
As of 2015-07-07 00:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (86 votes), past polls