Re^3: SIG CHLD IGNORE and wait at same time

I don't think it was race condition in this case, because this code should work with and without SIG CHLD IGNORE statement.

Fair enough; your further testing speaks to that. I'd still recommend setting up the handler before the kill, as a matter of good practice if nothing else.

Well, for example I want to reap zombies while program run, but at the same time I want to wait all child processes at exit.

OK. Luckily, that's quite easy to do, with only one wait in your code. See perlipc for more info, but here's a handler inspired by that:

use POSIX ':sys_wait_h'; # WNOHANG
my %pids; # Parent's hash of child pids

$SIG{CHLD} = sub {
    local ($?, $!); # Don't change $! or $? outside handler
    until (-1 == (my $pid = waitpid(-1, WNOHANG))) {
        return if $pid == 0; # Processes still running
        next unless delete $pids{$pid};
        say "$pid exited with status $?";
    }
};
[download]

In your parent, just set $pids{$pid} = 1 every time you fork, and the SIGCHLD handler will clean them up. In your parent's main loop, you then know not to exit until %pids is empty. You need to track your pids somehow, if you intend to send signals to them, so you may as well take advantage of that.

Comment on Re^3: SIG CHLD IGNORE and wait at same time Select or Download Code

Replies are listed 'Best First'.
Re^4: SIG CHLD IGNORE and wait at same time by vsespb (Chaplain) on Aug 04, 2013 at 10:16 UTC
`In your parent's main loop, you then know not to exit until %pids is empty.` Yes, I already have %pid, but "until %pids is empty." means either "sleep()" call or 100% cpu "while(1)" loop. Something like usleep(10_000) while(%pids) will work. But this would be just workaround over non-working wait() call.	[reply] [d/l]
Re^5: SIG CHLD IGNORE and wait at same time by rjt (Curate) on Aug 04, 2013 at 11:21 UTC
"until %pids is empty." means either "sleep()" call or 100% cpu "while(1)" loop … But this would be just workaround over non-working wait() call. Actually, sleep without an argument translates to "sleep forever" (until interrupted). So `sleep while %pids;` consumes almost no CPU¹, as it will only check `%pids` when it's interrupted, likely by the very `SIGCHLD` you would like to trigger a check of `%pids`. You can't get much more optimal than that. I don't consider this common idiom a "workaround" at all, especially if you were just going to `wait()` in your main loop anyway (`wait/waitpid` get interrupted just like `sleep`, but Perl ensures they're transparently re-started after the signal handler returns). See Restartable System Calls (perlipc) for more information. If you still have reservations, you can always `exit` from your signal handler (as I think you may already have been doing in one of your examples) once it removes the last key from `%pids`, but then that leaves the question of what you are planning to do in your main loop: if you're just going to sleep or block, you probably won't gain anything. I hope this helps. ___________ 1. Sure, pathological situations with a (very) large flood of incoming signals would tax the CPU, but in that case, checking the size of a hash would still be insignificant.	[reply] [d/l] [select]