On Fri, Oct 21, 2022 at 8:33 AM Jacek Caban via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote: > >>>/How does this compare with Eric B's proposal at > >>>/>>>/https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? > >>>/>>//>>/My proposal was to reimplement (and extend) the native thread > >>>model />>/(win32) />>/instead of adding a new one, the advantage being > >>>that you don't need an />>/extra />/> threading layer between GCC and > >>>Windows. /> > > I agree! > > I agree as well and I expressed that on mingw-w64 ML when the patch was > introduced [1]. My main concern with the new threading model is that instead > of solving root of the problem, it introduces more fragmentation with no > clear benefit. > > On top of that, mcfgthread library is way more invasive than it needs to be. > It requires maintaining per-thread struct and reimplements a number of things > instead of leveraging OS capabilities. Author also plans to make invasive > changes to mingw-w64-crt, which go against it current approach of being > agnostic to threading model. > > Jacek > > [1] https://sourceforge.net/p/mingw-w64/mailman/message/37719727/
FWIW, Eric's proposal makes more practical sense. Right now, people ship many permutations of the compiler: x86, x64, x86+x64 dw2, sjlj (rarely), seh win32, posix+winpthread This is not sustainable, and certain combinations are largely incompatible (which makes for instance providing a windows release of MySpecialLibrary.dll confusing). We used to have a matrix of combinations on the website, but I see that that's no longer present. In any case, it took a long time for sjlj to fall out of vogue (maybe old habits die hard?). That implies, to me, that winpthreads similarly won't be deprecated, it'll just be yet another set of archives to download and confuse people with.
