News for hackers. Stuff that matters.
Re:0+0 > 0: C++ thread-local storage performance by atq2119 on Monday February 17, 2025 @08:37AM (#43078859)
Take a look at https://maskray.me/blog/2021-02-14-all-about-thread-local-st...

I think what you want is to force the "initial exec" model using an attribute to get the more efficient code.

IIRC this (or something equivalent) is what libGL does because basically every OpenGL function call needs to read the thread-local variable holding the current GL context.

The downside is that dlopen()ing your library may fail.

Re:0+0 > 0: C++ thread-local storage performance by yosefk on Monday February 17, 2025 @08:47AM (#43078961)
Doesn't the "initial exec" model require the user to run the executable with LD_PRELOAD=your.so or linking against your.so (DT_NEEDED)? eg would it work with a Python extension module which is dlopen'd at runtime?
Re:0+0 > 0: C++ thread-local storage performance by fweimer on Monday February 17, 2025 @09:00AM (#43079078)
It depends on the amount of TLS and the number of objects that do this, and the C library. In glibc, we have a small static TLS reservation dedicated for use by dlopen of shared objects with initial-exec.