On Wed, 28 Oct 2020, Jeremy Drake via Mingw-w64-public wrote:
On Wed, 28 Oct 2020, Martin Storsjö wrote:
Don't run the destructors directly after executing the user thread
function. This allows running other TLS callbacks (e.g. tls_atexit.c)
before running destructors registered via pthread_key_create (which
can be used by the libgcc emutls allocations, if libgcc is built with
the pthread thread model).
This does not work for me if winpthreads is dynamically linked. In that
case, winpthread DLL's __dyn_tls_callback is called before the
executable's tls_callback, so emutls_destroy is still called before the
executable's tls destructors are processed. It works properly if
winpthreads is statically linked though.
Oh crap, that's true.
At this point, it's easy to conclude that native TLS is pretty convenient,
as the allocations are managed entirely by the OS...
For emutls, the only safe thing would essentially be to have the TLS dtors
be run via the same mechanism (pthread_create_key or __mingwthr_key_dtor)
as emutls (i.e. as long as both emutls and TLS dtors are provided by
libgcc+libsupc++ and both are built with the same threading model).
Even then, the two key destructors are called in the opposite order
(opposite to how TLS dtors and emutls need to be deallocated). But - I
found this bit:
https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_key_create.html
The order of destructor calls is unspecified if more than one destructor
exists for a thread when it exits.
So with that in mind, winpthread _could_ flip the order it runs the
destructors, and it would work with the libsupc++ implementation of
__cxa_thread_atexit. Then winpthreads would run dtors in a different order
than both glibc and darwin's, but it would run in the right order for this
usecase. A little bit brittle maybe though?
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
