There are alot of issues you have to deal with in your scenario, but here is one tip which you may find useful in dealing with long-cgi-processes.

#!/usr/bin/perl
use warnings;
use strict;

#Benjamin Goldberg 
#The Apache process does NOT wait for the CGI process to exit, it wait
+s 
#for the pipes to be closed.  (Note that if the CGI is a NPH script, t
+hen 
#it does waitpid() for the script to exit). 
#Thus, you do not really need a child process -- you can have your CGI
+ 
#process transmute itself into whatever you would have the child proce
+ss 
#do, by doing something like: 

$| = 1;         # need either this or to explicitly flush stdout, etc.
+ 
print "Content-type: text/plain\n\n";
print "Going to start the fork now\n";
open( STDIN, "</dev/null");
open( STDOUT, ">>/dev/null");
open( STDERR, ">>/path/to/logfile");
fork and exit;
exec "program that would be the child process";


#Apache waits for all children to close the pipes to apache.  It 
#does not wait for them to actually exit -- think ... how in the world
+ 
#could it *possibly* know that those processes were really spawned fro
+m 
#the CGI process?  Answer:  It can't.  It can only know that *somethin
+g* 
#still has an open filedescriptor which points to one of the pipes tha
+t 
#apache created to capture the CGI's stdout and stderr.  As long as on
+e 
#of these pipes is open, then apache waits.
[download]