在 2022/10/21 19:54, i.nix...@autistici.org 写道:
I have a questions:1) wouldn't it be logical not to write yet another implementation of pthreads-wor-windows, but to make changes to the winpthreads library because it's already supported by GCC? (maybe I don’t know about some reasons why it wasn’t done ...)
While it is possible to rebuild winpthreads from scratch, I don't think it's
worth:
* There are many POSIX facilities that we don't support: rwlock,
cancellation, signals, etc.
* GCC can choose to implement `std::thread` etc. on C11 <threads.h>,
which libcxx already has, but I haven't tested it.
(mcfgthread also has a C11 header, but not one for libcxx.)
It seems to me the ideal and logical option is to make your implementation part of GCC, as suggested by Eric B.the advantages are as follows: 1) we will get a high-quality native implementation. 2) there is no need to add another thread model for GCC.3) with dynamic linking there is no need to ship another dll with the program. (Windows users really don't like this =))
Jacek Caban, who is also a mingw-w64 developer, expressed the same idea a few
days ago.
While integrating mcfgthread into gcc is practically possible, my concerns are:
* GCC never provides a threading library. It always depends on glibc,
musl, win32 APIs, winpthreads, etc.
* Tampering with the win32 thread model in a dramatic way is not
acceptiable due to backwards compatibility. There are distributions
that have win32 as the default thread model, such as Debian.
* I personally need more control for future development, for example,
re-implement pthread or adding libcxx support, which doesn't fit in
GCC.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
