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.
And as I already said - it won't be working currently either. I'm not preventing it from working if it does.
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.
How is it going to be dependent in any way on a module that was loaded after it was?!