Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
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 rifling through the Monastery: (12)
As of 2014-08-29 14:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (280 votes), past polls