Creating a thread is already very expensive, in a sane program your ten TLS constructors shouldn't come even close to the amount of bookkeeping that the kernel has to do to spin up a new thread.

Also creating a thread, doing little work and exiting immediately is a bad use of threads -- I don't think that everyone using thread_local should be punished to better support poorly written programs. Most threads are long-running and most programs spin up a bunch of worker threads at initialization time, I'd argue variable access time is way more important than thread startup time.

In a simple benchmark, creating a thread & waiting on it in a loop (pthread_create+pthread_join) takes 0.03ms = 30000ns, so running a bunch of constructors of a bunch of libraries could actually be a non-insignificant amount of time.

Do agree that threadlocal read speed should be a lot more important, but it'd quite suck if the "acceptable performance" thread usage approaches would vary dramatically depending on what libraries you've (or something else) has unrelatedly loaded. (though maybe other overheads might appear from other sources similarly, keeping this not the most important slowdown, idk)

If you make use of dynamic linking namespaces and some sort of runtime, you can make it impossible to enter specific libraries in certain libraries in certain threads and avoid that cost. If your application is large enough that you can't keep track of deps, then you may want something like that in your application if you're not willing to split it into multiple processes.

> Creating a thread is already very expensive, in a sane program your ten TLS constructors shouldn't come even close to the amount of bookkeeping that the kernel has to do to spin up a new thread.

This is not true, at least on Linux. With appropriate settings (e.g. a small stack) thread creation can be extremely cheap.