This is also an incomplete suggestion and I'm looking forward about the replies from others. Esp. given the recent daemon/sysread thread where some framework for forking/daemon-use would be also have been useful for the larger picture (avoiding zombies and race conditions by not reinventing an (*) overly complex and fragile process management...).

Ignoring threads and the module for now:

A true zombie is fairly lightweight and consists of not much more than kernel data containing the process exist status, which still needs to be returned to the invoking process or init. Check the man pages of perlvar (%SIG,SIGCHLD) and perlipc for details. You have zombies when you

• do not handle SIGCHLD with a signal handler exor
• do not wait for exiting children with wait or waitpid. If you have the full list of processes, you could use a non-blocking waitpid call in the parent to check/reap zombies (be very paranoid to avoid fragile code and races, and be prepared to allow for impossible bugs like this one: job-management vs. waitpid in the Perl Shell - which I still don't understand, despite my work-around).

Myself, I'd probably try the scrap from perldoc -f waitpid and add it to the parent process in a regularly visited code path.

Or better yet, grep docs and source of the fork manager module for interesting methods using wait/waitpid to avoid yet another run-in with races -> (*).

HTH & looking forward to more module-specific replies,
Peter