On 10/12/22 06:06, LIU Hao wrote:
在 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.
I'd argue that this requirement will need to be relaxed at some point
and fixing threading support would be a good reason to do that. If
someone really wants win9x, winpthreads could still be used (or simply
one could use an older version of GCC).
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.
It should be possible to implement that without a custom thread-control
structure, Windows API combined with msvcrt (urct) provides means for
achieving that.
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.
Well, sure, but that's not a technical argument.
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
