> Is this a deliberate performance tradeoff, benefitting code with lots of thread_locals and starting threads constantly, with each thread using few of the thread_locals, and some thread_locals having slow constructors? But such code isn't great to begin with?
Actually, thread globals only being used in some threads is probably the common case. Remember that threads are not only created by the main executable but often also by libraries. Keeping per-thread overhead low until the TLS variables are actually needed sounds like a good design goal.
> funtrace sidesteps the TLS constructor problem by interposing pthread_create, and initializing its thread_locals in its pthread_create wrapper
Sounds extremely fragile. What if someone calls clone() directly or another (possibly new) function to create a thread.
I dunno if extremely fragile; I recommend trying funtrace on your own code - pretty sure it will work out of the box! But, what's less fragile than interposing pthread_create which doesn't add a load and a branch to every function call and return which is where a tracing profiler will need to access TLS?..
In any case, one point of funtrace is that it's small (~1K LOC runtime) and you can tweak it easily, including calling its TLS init code from your threads if you don't create them with pthread_create "like most people" - even without this issue, people do "green threads" with setcontext/getcontext and who knows what else, which will need its own hacks to support, and so I think that an easily hackable runtime is a good thing given how hard it is to do this in a one-size-fits-all fashion.
As a counterexample, LLVM XRay, a tracing profiler from Google which is at least 10x bigger than funtrace (if you don't count the compiler instrumentation they introduced), took almost a decade to gain shared library support, and it's not done yet. So I think "small and hackable" has its advantages.
Actually, thread globals only being used in some threads is probably the common case. Remember that threads are not only created by the main executable but often also by libraries. Keeping per-thread overhead low until the TLS variables are actually needed sounds like a good design goal.
> funtrace sidesteps the TLS constructor problem by interposing pthread_create, and initializing its thread_locals in its pthread_create wrapper
Sounds extremely fragile. What if someone calls clone() directly or another (possibly new) function to create a thread.