3 ms·
I don't buy the static linking part - we already generate a single function in the linked binary that calls all static constructors from all translation units,
by alexvitkov 2y ago
I don't buy the static linking part - we already generate a single function in the linked binary that calls all static constructors from all translation units, the same thing can be done for TLS constructors (what I called construct_thread_locals() in parent), and force the user to call that manually on thread creation, or call it as part of std::thread.
Dynamic linking is a whole other beast, and maybe for thread_local's in a DLL it's acceptable (or the only possible way?) to do construct them lazily - if you're using DLL+TLS+global constructors you deserve the pain.
- comex 2y agoThe problem is that dynamic linking is the norm. If you're writing a specific application, that's one thing. But if you're writing some random C++ library then you usually have no idea whether it will be compiled into an executable or a shared library. If TLS is slow in either of those cases, then the only solution is to not use TLS at all.