在 2022/10/12 03:55, Jacek Caban 写道:
Is there anything that mcfgthread achieves that can't be fixed in GCC's win32 model? This sounds to me like that GCC is the right place to fix things, possibly by merging parts of mcfgthread into GCC itself. I really don't like the idea of adding another threading model instead of fixing the existing one. It adds more fragmentation, more maintenance and more user confusion. I think it's better to fix the root of threading support problems instead.
The obvious problem is that mcfgthread is functional on only Windows 7 and above, while (I don't know for sure) win32 should continue to work on XP, 2000, or even 9x.
Originally there was only mutex, condition variable, once flag, thread and thread-specific key in mcfgthread. When I considered that it should be possible to join with the main thread from another one, it would be necessary to have a static thread-control structure for the main thread, allocated upon library initialization.
(N.B. The Windows thread exit code is not an option, because pthread wants a `void*` which would be truncated on 64-bit Windows.)
Later, `__cxa_atexit()` was added to address the issue about order of destruction, which also required a destructor queue. The same went for `__cxa_at_quick_exit()`.
While some people do prefer static linking, ideally these global data should be unique within a single process, and were necessary to be part of a DLL. This approach was much similar to the legacy `mingwthrd` library.
Technically, this can be solved with named shared memory [1], and is not a requirement any more. Therefore it has become a personal preference, to not maintain something as a part of GCC, mostly due to their lack of enthusiasm about Windows.
[1] https://github.com/lhmouse/mcfgthread/issues/70 -- Best regards, LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
