http://qs321.pair.com?node_id=368830


in reply to Re^2: Perl cgi without mod_perl, your experience
in thread Perl cgi without mod_perl, your experience

That's actually not the best way to do it. Ideally, you would fork so that your processing does not tie up an apache child process at all. This is how we recommend handling long running jobs on the mod_perl list.
  • Comment on Re^3: Perl cgi without mod_perl, your experience

Replies are listed 'Best First'.
Re^4: Perl cgi without mod_perl, your experience
by stvn (Monsignor) on Jun 22, 2004 at 20:26 UTC

    From what I know about fork, and mod_perl, I can't understand why that would be the recommened way to handle this (and I am in no way claiming to know everything about fork/mod_perl, so I may be way off here). My understanding is that forking under mod_perl would result in a duplication of the apache child process, complete with mod_perl and all its goodies. Sure that could then be chopped off of the apache parent and set to live on its own by closing file-handles and such, but then I have a big-fat-apache zombie process which eventually will just need to get reaped by the OS's init process.

    How can that be better than hijacking an Apache process with the Cleanup phase for a little while? Am I grossly misunderstanding something here?

    -stvn
      You can avoid getting a zombie, and copy-on-write means that most of the memory is shared. This is all described in the mod_perl guide here. Now, if these things you do in the cleanup phase are very short, this is overkill, but for long-running jobs it's really the best option. Another good approach is to use a queue, so that you can just dump jobs onto it and move on, and a separate process monitors the queue and picks up jobs that apache adds to it.