在 2022/10/21 19:54, i.nixman@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