I happen to use a POE daemon, and track batch jobs through a table in MySQL. The web interface polls this table at regular intervals, and displays the progress (or the end-result) to the user. The POE daemon can process many jobs concurrently (through POE::Component::JobQueue and POE::Wheel::Run).

The advantage of that approach is that both sides are decoupled, and that you have detailed control over the resource consumption.

Update: Maybe you could make use of Apache2::SubProcess. That looks like a safe way to fork under mod_perl.

I don't know if you can call sleep (since that might rely on an underlying SIGALRM) - it's worth trying to see if you can) and if not you can (ab)use good old select undef, undef, undef, x.y; to sleep.

You could then have your child process create a file with the desired output when it is done (note that you don't simply want to check for the existence of the output file - you could end up with a partially-written file. Have the child process create into a temp file and then rename (which is atomic) to the output file).

Since you are periodically waking up (say every 1 sec) you can implement your timeout via a counter. On timeout, you can nuke the child process, print an apologetic page, remove the temp file and get on with life.

Not very nice, I know, but waking once a second isn't a burdensome operation and if it's a probably-long-running task, you probably don't need a greater resolution than that.

if ((my $pid == fork()) == 0) {
    exec 'ghostscript', @args;
} else {
    my $slept;
    while($slept++ < $alarmtime) {
        sleep 1;
        last unless kill 0, $pid; # see if it's still alive
    }
    kill 0, $pid or kill 15, $pid;
    wait;
}
[download]

That way you wouldn't need signal handlers. Oh wait... SIGCHLD and the wait()...

--shmem

update: added loop

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

The problem is that the request goes to call Ghostscript and never comes back, possibly because of some incompatibility with alarm.

I've since commented out all of the calls to alarm, and the problem remains.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

So it's not alarm then. If you call ghostscript the same way from a command-line perl program, does it also hang?