"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.