On Mon, 26 Apr 2021, Liu Hao wrote:
在 2021-04-26 04:20, Martin Storsjö 写道:
The exact behaviour for cases 3-5 differ between whether the two are linked
dynamically or statically against the CRT. I'm not sure if all the nuances
are worth mimicing though. (A function registered with at_quick_exit within
the DLL isn't called when quick_exit is called, regardless of whether the
main executable or the DLL calls it.)
However - if a DLL does at_quick_exit, and the DLL later is unloaded, we
might have an issue if we go with this kind of patch... But the MSVC
behaviour doesn't seem entirely consistent either?
Regarding your patch, it fails to build with clang due to function type
mismatches - at_quick_exit
takes an _PVFV, not an _onexit_t. (I also see that ucrtbase_compat.c
currently is wrong about this, it declares _crt_atexit with the wrong type
of parameter. I can send a standalone patch that fixes that.)
The purpose of `quick_exit()` is to just call `_Exit()`, but also allow users
to perform some custom cleanup, without invoking any static or thread_local
destructors.
So personally, I think that quick_exit callbacks registered by a DLL should
be discarded when the DLL is unloaded, because if otherwise the process calls
`quick_exit()`, those internal pointers will point to deallocated memory.
So, `atexit()` registers callbacks that will be invoked when a DLL is
unloaded, and `at_quick_exit()` registers callbacks that will be invoked upon
process termination, does it make any sense for a DLL to call the latter?
Probably, but only for DLLs that are residential until a process terminates.
I think it's of course worth something.
Indeed. The problem as I see it, is that we'd need some sort of unregister
function for the at_quick_exit mechanism, to be able to use them safely
from a DLL (because we can't assume DLLs aren't unloaded).
Or then just ignore functions passed to at_quick_exit() from within a DLL,
when using a dynamically linked CRT (which is the only choice in
mingw-w64) - which happens to be how MSVC seems to behave.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
