On Sun, 5 Jul 2026, LIU Hao wrote:
From e1887cbf28d13b14f368226b5387bb5e9624d542 Mon Sep 17 00:00:00 2001
From: LIU Hao <[email protected]>
Date: Wed, 1 Jul 2026 17:32:00 +0800
Subject: [PATCH] crt/tlsthrd: Do not run thread-local destructors upon
process
termination for win32 thread model
This is a reworked version of a556c6943c442465dc9a051bc6d3a6d452df4a1d that
affects only win32 thread model.
Like `pthread_key_create()`, destructors that are registered by
`___w64_mingwthr_add_key_dtor()` should not be called upon process
termination.
Signed-off-by: LIU Hao <[email protected]>
---
mingw-w64-crt/crt/tlsthrd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mingw-w64-crt/crt/tlsthrd.c b/mingw-w64-crt/crt/tlsthrd.c
index bebe27b37..729aa1c1a 100644
--- a/mingw-w64-crt/crt/tlsthrd.c
+++ b/mingw-w64-crt/crt/tlsthrd.c
@@ -131,7 +131,6 @@ __mingw_TLScallback (HANDLE __UNUSED_PARAM(hDllHandle),
__mingwthr_cs_init = 1;
break;
case DLL_PROCESS_DETACH:
- __mingwthr_run_key_dtors();
if (__mingwthr_cs_init == 1)
{
__mingwthr_key_t volatile *keyp, *t;
--
This might be acceptable.
It might be worth clarifying the commit message further that "win32 thread
model" specifically refers to libgcc (and implicitly through libgcc also
libstdc++); this code isn't used by other codepaths.
I'm not entirely convinced that this is the right thing to do in general -
I think this would lead to destructors not being executed in cases where I
think they would be executed in e.g. an MSVC build.
Does this cause e.g. destructors for user code TLS C++ objects in DLLs to
not be executed on process exit, for builds using libstdc++/libgcc?
This should at least affect fewer cases than the previous patch.
But overall, the problem is the same - destructors in DLLs on process
exist, when threads still may be running, really are tricky on Windows in
general. I think the conventional method is to fix this on the user code
side - but there's usually no single easy way of fixing it.
TL;DR - this patch shouldn't hurt me and my configurations I think, so I
won't block it, but I think it's principally slightly wrong.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
