Perrin Harkins schrieb:
On Mon, Jan 26, 2009 at 2:26 PM, Michael Ludwig <m...@as-guides.com>
wrote:
I think this is technically incorrect in that it does not match the
Apache/LibPHP execution model (which is what I think they're trying
to emulate), where the Apache/LibPHP process does not exit after
serving only a single request.
Well, is your goal to be exactly like PHP or is it to provide a fast
environment for non-persistent perl execution? Perl doesn't have the
same kind of reset switch for the interpreter, so creating a new one
each time is necessary.
I may be wrong but I used to think that PerlRun provides just that, a
non-persistent execution environment, just like LibPHP. Memory consumed
by the interpreter is not deallocated in either case. (Unless, of
course, I'm wrong.)
Setting MaxRequestsPerChild to 1 causes apache to prefork a new
process with a new interpreter for each request. This should be
faster than attempting to actually create a new interpreter, since
all it has to do is fork the parent process and forking is very
efficient on Linux and BSD.
Yes, relatively light-footed processes on these platforms. But if
forking was so efficient, why offer PerlRun?
PerlRun is effective in many situations but it will never be as
effective as forking a fresh process/interpreter.
That may or may not be true depending on what effect you want to
achieve. As for efficiency, I used to think that PerlRun had an edge
over forking in that respect. But well, I may be wrong.
PHP can leak memory, too. MaxRequestsPerChild is important, as it is
with Perl. Setting it to 1 in either case means throwing the baby out
with the bath water.
I disagree. In fact this was a common recommendation for use with
PerlRun in the old days when people had scripts that were just too
dirty to get running in a persistent environment.
Too dirty for more than one request on PerlRun? Never seen anything as
dirty as that.
But wait, I once came upon a homegrown "framework" that implemented an
HTTP redirect by printing the header, flushing the buffer and then
calling exit(), which terminated the Apache process. That was really
dirty. The icing on the cake was that it didn't close the database
handle, and I suspected it of being the culprit for the connection
leakage we were seeing. But lacking in-depth knowledge, I never got to
the ground of it.
Note the doc for PerlRun says: "This module is meant for 'Dirty' CGI
Perl scripts [...]". Note it says "Dirty" with a capital D.
Best,
Michael Ludwig
