On Thu, 2 Aug 2018, Martin Storsjö wrote:
On Thu, 2 Aug 2018, Liu Hao wrote:
在 2018/8/2 13:56, Martin Storsjö 写道:
Yes, a responsible user would join all his threads before calling exit()
or returning from main, there's no disagreement about that.
But the problematic case I'm thinking about is when you load and unload
e.g. plugins, which may contain TLS objects. If more than one long
running threads (which aren't stopped meanwhile) touch the plugin while
it is loaded (with proper synchronization of course), you'll have leaks.
// Martin
I don't know how many people unload DLLs in practice. AFAIU once a DLL
is loaded and a function from it is called, it is virtually impossible
to eliminate the possibility of references of anything in that DLL,
especially C++ RTTI, virtual functions, specialized function templates,
etc. If people don't ever unload a DLL, thread local objects in that DLL
will be considered reachable and therefore are not leaks.
VLC is the specific example I have in mind, which regularly loads and
unloads DLL plugins. On unload, nothing in the remaining process should
have any handle to anything sourced from this DLL. The plugins themselves
only expose a C API although they internally can use C++.
VLC also has numerous threads running. I'm not sure if more than one
thread actually will interact with each plugin though, and if that is the
same as does the loading of the plugin, or if it might be a different one.
... which is the reason why I think this should be a reasonable behaviour.
But as MSVC's implementation of this doesn't call TLS destructors for
other threads, I guess it's fine to just document this as the intended
behaviour, and have VLC reconsider their use of TLS objects here (either
it's all actually done on the same thread that unloads the DLL, or threads
that touched it are joined before unloading it, or they shouldn't use it).
// Martin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
