SF>>The number of the final TSRM resource id that was loaded will be the SF>>size of the table they're stored in, plus one (to keep life simple). SF>>So we pick up that figure and call it 'table_size'. Then we subtract SF>>the number of modules registered in the dl_module_count.
I'm not sure why is this conclusion. Do you suppose only modules allocate IDs and each of them allocates exactly one? What about Zend extensions that also allocate IDs but do not have modules? What about modules not needing globals? And what about dl()ed modules? Unless I am missing some cruicial bits, this assumption seems to me very dangerous one. SF>>Since dynamically loaded modules are the last ones to load, they're the Are you sure they are? You can load an extension on another extension startup, for example. Or on module startup. Or on any other stage of startup procedure, for that matter, starting with module startup. You seem to be relying on very precise order of events for this to work, which is not guaranteed to happen. SF>>care about dl'd modules at this point. Nothing else actually needs its SF>>resource freeing before tsrm_shutdown() (which cleans up everything that Zend extensions do too. SF>>list. But freeing a module's resources slightly early during shutdown SF>>doesn't do it any harm anyway - and the big thing here's to guarantee the I don't like it at all. Really. If the code does not do what it was intended to do, it's no excuse to say "well, nothing really bad happened" - maybe not now, but what will happen in a year when another dozen of extensions arrives? If the code doesn't do exactly the clearly defined things it is supposed to do - we are literally inviting trouble for ourselves later on the way. I thin such code is way too dangerous. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
