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. Memory consumed > by the interpreter is not deallocated in either case. (Unless, of > course, I'm wrong.)
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(); > 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. It's a better option for people who have relatively clean code and don't mind that modules will be persistent but want their script's globals cleared every time. > Too dirty for more than one request on PerlRun? Never seen anything as > dirty as that. 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. > 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. > 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. - Perrin
