Also, if the work to be done is “substantial,” you might not want to implement it in the CGI script at all, for various reasons.   Instead, you might conceive of the CGI script strictly as a user-interface, in which you can queue work-requests (say, they're written to a database table), observe the completion status of requests you've queued, and retrieve the results selectively.   Meanwhile, a back-end processor or processors, say written in Perl, poll this queue and carry out the work.   (They put the results in a directory that’s mutually accessible and note in the database where they put it.)   Now, the CGI system is back to doing what it customarily does:   handling very brief, “get in then get out in a few milliseconds” requests.   The worker-bee daemons can be anywhere.   And results, once generated, can be viewed more than one time at will.   How you devise the daemons to work, <i.e. forking or not, is entirely up to you and no longer of any concern to CGI.