Perrin Harkins schrieb:
On Mon, Jan 26, 2009 at 4:15 PM, Michael Ludwig <m...@as-guides.com>
wrote:
I may be wrong but I used to think that PerlRun provides just that, a
non-persistent execution environment, just like LibPHP.
It's not really possible in perl. PerlRun attempts to fake it by
removing anything added to the symbol table in the package it creates
for your script. However, if you load any module or use a namespace
in any way at all, you completely defeat PerlRun. For example, it
will not clear this:
$MyPackage::Count++;
Or this:
$MyCache::DBH = get_dbh();
Okay, I see. Must admit that I've only ever used Apache::Registry and
PerlHandler, or PerlResponseHandler in 2.0.
Yes, relatively light-footed processes on these platforms. But if
forking was so efficient, why offer PerlRun?
Not forking is more efficient, but since the perl interpreter can't be
reset it's not as foolproof.
If there was nothing as dirty as that, then PerlRun would be the
answer to mod_perlite. But, as I explained, PerlRun is not enough for
everyone.
Now I get it. Thanks for clarifying!
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.
PerlRun and Registry usually intercept exit() calls.
Don't remember whether that was exit() or CORE::exit().
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.
Could be, especially since it probably didn't really exit.
I seem to remember adding log statements to the routine closing the
handle and seeing these triggered on server shutdown, suggesting the
process didn't really exit when exit() or CORE::exit() got called.
Certainly a very undesirable setup.
Michael Ludwig
