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...