DR>> doesn't work (because the destructor is called from DR>> request_shutdown). I'm pretty sure that there is some way to get this DR>> working in a decent way... which might perhaps not be the nicest DR>> solution.
The problem is that we have following set of requirements: 1. Modules should be shut down before destructors are called 2. Modules shutdown should free module resources 3. Some modules shutdown should "shut down" subsystems they implement 4. Destructors should not use other objects they don't have direct link to - such as global objects, etc. Due to 1 and 3, destructors will be unable to use module subsystems, at least for the modules that do some shutdowns (like closing connections, etc.). Also, due to 2, unless we have a way for an object to "hold" a resource, they are unable to use resources. However, even if we make destructors to be able to use these resources, who is going to shut the resources down afterwards? Now, one of the ways would be to make two "shutdown points" - "early" and "late", shutting down before and after objects shutdown. Now, "late shutdown" modules would be unable to use any of the PHP variables while "early" shutdown modules would be unable to clean up any resources. Maybe we can have two shutdown callbacks - "finalize", where the module should do all final tasks, such as commit transactions, flush files, write down sessions, clean up hashtables, etc. - and "shutdown", where the module should shut down subsystems, such as close connections, destroy resources and hashes, etc. It should be checked that all modules indeed fit this scheme, however. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
