Re: Adding a new thread model to GCC

[NightStrike <nightstrike@gmail.com>]

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.