Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So this was only a MSVC bug? Most people compile Pd with MinGW, which would explain why we never ran into this issue.

Do you happen to have a link to the original MSVC bug report (i.e. the wrong thread locals, not the performance regression)?



Note that MinGW uses libwinpthread, which is known to have slow TLS behavior anyway (I've observed a 100% overhead compared to running the same program under WSL using a linux-native GCC). c.f. https://github.com/msys2/MINGW-packages/discussions/13259


I haven't looked into it, but going through the release notes for tlsGuards showed this - though not directly a bug report

https://learn.microsoft.com/en-us/cpp/overview/cpp-conforman...

and also the implementation in "clang" (for "clang-cl" being conformant with MSVC) - https://reviews.llvm.org/D115456#3217595

then last year clang-cl also added ways to disable this (if need to), probably this hit some internal issue and had to be resolved. Maybe "thread_local" have become more widely used (unlike OS specific "TlsAlloc")


Thanks! Fortunately, this issue does not affect us because our thread locals are all zero initialized integers or pointers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: