On 11/15/22 15:17, LIU Hao wrote:
I think that when there is a real bug, we should fix it. As for
standard themselves, I think that C/C++ standards are important.
Praising POSIX-alike standards for mingw-w64, who's CRT is a wrapper
around Windows system CRT, seems a bit misplaced for me. Using it
makes sense sometimes, but I don't think it should be a goal on its
own. For full POSIX compatibility, one needs something like Cygwin,
MSYS or WSL2 anyway.
Do we conclude that we shouldn't introduce the extra complexity, and
should just maintain the same behavior as MSVC, although it's
non-standard and causes deadlocks or crashes occasionally? This
decision is reasonable on itself; and if that is the decision, then
fair enough.
As I mentioned, I think that real bugs should be fixed. But we need
proper understanding of the problem and find root of it. For example you
said that:
> 1. In a DLL, destructors of static objects and callbacks that are
registered
> with `atexit()`, are executed by `LdrShutdownProcess()`, after all
the other
> thread have been terminated `ZwTerminateProcessO(NULL, status)`. This
means
> that, if another thread has been terminated while holding a mutex,
the mutex
> can never get unlocked. If a destructor attempts to lock the same mutex,
> deadlocks will occur. Destructors of executables do not suffer from this
> issue, because they are executed before `RtlExitUserProcess()`.
This is simply not true when msvcrt is properly used. atexit callbacks
are executed by msvcrt before calling ExitProcess(), see Wine
implementation (callbacks are invoked by _cexit()):
https://gitlab.winehq.org/jacek/wine/-/blob/master/dlls/msvcrt/exit.c#L364
It's possible that mingw-w64 does not use it properly, but in that case
we should identify the exact problem and simply use it properly.
Jacek
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
