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

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.

Comment on Re^4: SIG CHLD IGNORE and wait at same time Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]