in reply to Re: SIG CHLD IGNORE and wait at same time
in thread SIG CHLD IGNORE and wait at same time

Try swapping those two statements, for a start.
No, it did not help.
You have a race condition in your parent code:
I don't think it was race condition in this case, because this code should work with and without SIG CHLD IGNORE statement.
IGNORE' is most useful when you really don't care.
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.
I'd recommend just using your own wait() or waitpid() loop, perhaps in conjunction with a custom signal handler if you need out-of-band child exit notifications.
Yes, as I told, this fixes problem: 
$SIG{CHLD} = sub { while( wait() != -1 ){ print STDERR "wait0\n"}; };

[download]
so probably there is a workaround.
usually returns -1
Yes, indeed. Ok, thanks.

Replies are listed 'Best First'.
Re^3: SIG CHLD IGNORE and wait at same time
by rjt (Curate) on Aug 04, 2013 at 03:47 UTC
    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.

[reply]
[d/l]
[select]
      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]
        "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 CPU1, 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]

In Section Seekers of Perl Wisdom