note sundialsvc4 <p> Also, if the work to be done is &ldquo;substantial,&rdquo; you might not want to implement it <em>in</em> the CGI script at all, for various reasons. &nbsp; 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. &nbsp; Meanwhile, a back-end processor or processors, say written in Perl, poll this queue and carry out the work. &nbsp; (They put the results in a directory that&rsquo;s mutually accessible and note in the database where they put it.) &nbsp; Now, the CGI system is back to doing what it customarily does: &nbsp; handling very brief, &ldquo;get in then get out in a few milliseconds&rdquo; requests. &nbsp; The worker-bee daemons can be anywhere. &nbsp; And results, once generated, can be viewed more than one time at will. &nbsp; How you devise the daemons to work, <i.e.</i> forking or not, is entirely up to you and no longer of any concern to CGI. </p> 1002431 1002431