Re: Re: [PATCH] Automatic module globals management

SF>>crash might well appear random.) The best way to deal with an extension SF>>declaring more than one thread resource would be to build it as static. But That's a good advice but not practical at all. :) Static extensions can not be distributed as a product or a package, for example. SF>>being in the DL_UNLOAD queue. It doesn't matter when that happens - SF>>the unload order isn't changed, the same resource id can't be freed SF>>twice, and all the other actions within the module_destructor are SF>>module-related rather than TSRM-related. What if resource dtor of previous module uses some global from later-freed module (which is perfectly legal as long as the order is correct) and you free wrong ID? Kaboom. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115