fork is your friend. Fork off a copy of your script and have it do whatever it needs to do. A fork + exec may be better, if you want to do something else in its place.

Caveat - if you're running in a mod_perl environment, you're gonna fork your entire apache process, which has memory overhead concerns among other issues that I always seem to forget. Filehandles, is it? Only do it here if you absolutely have to. CGIs? No sweat.

From there, just proceed as before - refresh the user back to some other page, and when your forked process completes, give it someway to flag its being finished. Touch a file, update a row in a database, something. Something that can be a quick and simple check for the front end to do.

To show the user the changes, there are several approaches - have 'em constantly click a button ("Am I done yet?") to refresh the page and display results if appropriate. Or bring up a "loading..." screen that watches for the update and refreshes when it gets it (note that this blocks the user), or do something fancy and ajaxy that autorefreshes (or gives a refresh button) when the data is actually there.

OK, I'l give that a try. Thanks for your help. (I don't usually accept being told to fork off, but I suppose this time it's ok!!)

I've been reading up on this and have implemented the fork:


if ($pid = fork) { 
print "I am parent\n"; 
} elsif (defined $pid) { 
print "I am child\n"; 
sleep 5; 
print "Child is done\n"; 
} else { 
die "Major error: $!"; 
} 
print "PID: $$\n";
[download]

However I need the child to run in the background, for the browser to be freed up on printing the parent. Can anyone point me in the right direction, please?

merlyn has an article on this topic.

-derby

I asked a related question in Managing a long running server side process using CGI which garnered some good answers.