在 2020/10/30 上午1:10, Jeremy Drake via Mingw-w64-public 写道: > On Thu, 29 Oct 2020, Liu Hao wrote: > >> As far as I can tell it is only required by the c++ standard that >> thread_local objects are destroyed in the reverse order that they have >> been constructed and prior to any static destructor, and with Jeremy's >> patch it is guaranteed I think. The others may execute in arbitrary >> order. > > > My patch did not change any ordering. With Martin's patches and my patch, > thread_local destructors still run after static destructors (at least for > the executable, at FreeLibrary the destructor order is correct for a DLL). > >
AFACT calling `FreeLibrary()` to unload winpthreads should be considered invalid. So the issue only emerges when the process exits. I have a little hazy memory about this so feel welcome to correct me: 0) The user program calls `exit()` or returns from `main()`. 1) `exit()` is called, which invokes callbacks registered with `atexit()` in reverse order. 2) `ExitProcess()` is called, which terminates all the other threads. 3) With only one thread in the process, all `DllMain()` functions and TLS callbacks receive a `DLL_PROCESS_DETACH` notification with the `lpReserved` parameter set to non-null. I suspect that static destructors are invoked as a part of Step 1), but thread_local destructors are invoked as a part of Step 3). It might be resolved by overriding the `exit()` function so we can take this last chance to destroy thread_local objects of the calling thread. There should be a thread cleanup function exported by winpthreads, but the CRT had better have a weak one for the `win32` thread model. Maybe `__mingw_cxa_thread_finalize()` is a good name for it (this name comes from the `__cxa_atexit()` vs. `__cxa_finalize()` thing). -- Best regards, LH_Mouse
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
