On Thu, 5 Dec 2024, LIU Hao wrote:
在 2024-12-05 20:38, Martin Storsjö 写道:
When the libstdc++/libsupc++ implementation of __cxa_thread_atexit is
used in conjunction with emulated TLS, both emutls and libsupc++
register destructors to be executed via pthread_key_create; one for
freeing the per-thread memory allocated for the TLS objects, and
one for executing the destructors. They are registered in a sequential
order; first emutls registers the destructor for freeing the memory,
followed by libsupc++ registers a destructor for running the TLS
^ 'which' registers a destructor ...
Thanks, will fix.
object destructors.
Therefore, running the pthread key destructors in reverse order makes
sure that the TLS object destructors are called (via libsupc++) before
their memory is deallocated (via emutls).
This pattern also matches how destructors normally are executed - in
opposite order compared with how they were constructors.
---
This part of the fix should at least work the same regardless of
whether winpthreads is in a separate DLL or statically linked into
the end user executable.
---
mingw-w64-libraries/winpthreads/src/thread.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
This idea sounds correct to me.
Thanks - so I guess this patch could be pushed on its own, even if we
don't yet figure out a good way forward with the other one.
Technically, memory that is allocated by emutls should always be the last
cleanup before a thread terminates. With winpthreads I don't see how it can
be implemented.
Indeed, it seems quite complicated.
If we could force libstdc++ to prefer providing its own
__cxa_thread_atexit, which uses __gthread_key_create for registering the
destructor, then we'd have both emutls and __cxa_thread_atexit dtors
registered via the one and same mechanism, and they both should execute in
a consistent order.
But getting rid of our __cxa_thread_atexit, or making it available only in
some build configurations, also seems messy and like a step backwards...
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
