Re: Forking to an interactive program under mod

On Dec 12, 2006, at 6:13 PM, Robert Landrum wrote:

> Alex Beamish wrote:
>> What I'm trying to do is come up with scaled page images from a
>> PDF on the fly. Thus, I want to launch Ghostscript and then ask
>> for a couple of page images. So, launching Ghostscript and getting
>> the first page might happen on the first request; subsequent
>> requests would come back to the Ghostscript session left running
>> from the first request, and thus would be able to quickly produce
>> the required page image.
>> Suggestions welcome.
>
> What you're gonna need is a daemon that lives outside of mod_perl.
> It's job will be to answer ghost script requests made from within
> your mod_perl handler, track open files, purge unused files, and
> generally do all the things you want to do.  I don't really see a
> clean way to do it otherwise.

I'm going to agree with that.

There's no way to make sure that you'll have the same apache instance
handle each request.   You need to either have an external daemon
handle sessions ( and apache + cookies will id which session a user
has ) or you'll need to forget about open files and resuming
sessions, and just open files on every request.

I'd probably go for the latter option.  It sounds like you'll have a
lot of overhead with  opening files on each request, but if you have
a daemon handle it, you're going to have to write a ton of logic to
handle
    how many concurrent files can be open
    what is the timeout
    what happens on errors

my  .02¢ -- keep the whole thing in MP, don't fork, write a
wrapperclass to "save state" and resume on what you're doing with the
ghostscript files, and serialize that data / save it  with
Apache::Session.

Robert, Jonathon,

Interesting suggestions, thank you, and I'm coming around to the idea that a daemon will need to be used for the heavy lifting .. and then perhaps mod_perl can communicate with the daemon using named pipes ..

The whole point of this exercise is to keep all of the page information in memory so that when Ghostscript gets another page request it can service it right away, rather having to reload everything all over again. Lower latency, at the cost of higher memory requirements. So that tells me I don't want to load Ghostscript each time a new request comes in.

I'll deal with multiple documents with some combination of stale timers and LRU slots, but that's not really what I see as the most complicated or difficult part of this problem. For this particular application, my inactivity timer will probably by 10-15 minutes, and I'll expect to have 6-8 documents open at any given time, so it shouldn't be a big drain on memory. And I will probably be able to set something up that signals that a document has been expired as well .. (this is just me thinking out loud) ..

Thanks for your feedback .. I think named pipes is my next focus.

Cheers,

Re: Forking to an interactive program under mod_perl