Do the replies to Managing a long running server side process using CGI help?

There's a lot to go through there, but I am trying to avoid the CRON path. Just seems kludgy to me

However a thought hit me, and I'll have to reread the link you posted a few times to see if it's in there:

Is it possible to have a perl script, initiated from a browser, manually construct the proper HTTP::Response, and send it in the middle of my perl script? Theoretically, that would free the browser at the client end, and the rest of the perl script would contain the child code, which has no output, and keeps on running till completion.

Is such a beast possible? And even if so, how dangerous would it be?

That's a lot of "ifs" but just trying to look at it from a different perspective

There's a lot to go through there, but I am trying to avoid the CRON path. Just seems kludgy to me

Not really. If you need something to run independent from webcalls, that's how you should design it. One way of avoiding CRON would be to have a background process that always runs and get's controlled from the CGI scripts via interprocess messaging. There are many, many solutions on how to do this. As the author of the Net::Clacks module, this is what i usually recommend (since then i would be able to help you if you run into problems). There's a slightly outdated Howto on PM, see Interprocess messaging with Net::Clacks, and the package comes with some example programs as well.

perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

Did you get as far as my own reply and its follow up in that thread? It looks like a pretty good fit for what you want. The key is the session management stuff that allows the long running app to communicate back to the manager app.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond