I don't know where to place this, but I recently made a discovery. Our systems are not using ModPerl, we're using FastCGI. The FastCGI parses any HTML document, and if it has our form of a server side include, our perl module gets the information and returns the results of the command to the FastCGI parser.

But, it came time to do some "parallel" processing, and I found that the fork() command is not a good thing to do, because any call to exit() from a child process causes the FastCGI to continue on. The FastCGI didn't handle child processes, either, meaning that the machine ended up with quite a few zombies. Since not all of the information was getting back to the FastCGI program, it had to be done another way.

I found that you can use:

Use Symbol;
   ...
my $handle = gensym();
my $pid;
if ($pid = open $handle, "-|") {
} else {
}
[download]

and the children will just print directly to STDOUT. The parent listens via the $handle, which can be added to an IO::Select, handled using $select->can_read(). It turns out that now there are no zombies, all of the information is getting back, and the thing actually WORKS! (Wow). So, if you end up writing in an fcgi environment with your perl and have to kill some kids, use an open command instead of a fork() command. It's the only real way to stick a fork() in 'em! Add this to your "gee whiz" file and move along to better quality information.

   Joe sharktooth@innocent.com