As far as I can tell it's a bug. By the way, we're not talking about a
leak that happens too often - unless you're spawning and killing threads
very often (in which case TSRM is very inefficient regardless of
anything). The leak would happen per-terminated thread.
Good call. The backstory is that George noticed a leak in the
PHP::Interpreter Perl module and I saw the same thing in my Runkit_Sandbox
class. Both of these spawn a thread context when they instantiate so in
this case request == thread (and yes, I acknowledge it's an edge case
relative to real-world uses, but it does highlight an otherwise unnoticed
problem).
I temporarily plugged the constants leak (90k+ per request) by using the
patch below (though it's inefficient for obvious reasons), but rsrc_plist
will take a slightly different approach (heading out the door now so no
time
to think it through).
90K+ per request sounds wrong. I guess that you're either measuring right
after the server startup, when the threads are not yet initialized - and
then every request initiates a new thread; Or you're using a very odd web
server that spawns a thread for each incoming request (bad idea!). If
it's the former, then that leak is actually not nearly as bad as you
thought, if it's the latter... Fixing that leak should be the least of
your worries :)
You're right (see above).
Are you sure it's not leaking the global constants table with the
zend_shutdown_constants() removed from zend_shutdown()?
valgrind says no. To be honest I havn't gone looking to see where the
global table is cleaned up...Just got back home...
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
