3 ms·
In general, every access to a TLS variable involves a function call, which may allocate. This can only be optimized out in certain models. Note that the overhe
by o11c 2y ago
In general, every access to a TLS variable involves a function call, which may allocate. This can only be optimized out in certain models.
Note that the overhead of this is sufficient such that e.g. OpenGL libraries lie and act as if they were loaded at program start even when actually `dlopen`ed, and libc cheats to let them work. Some other libraries try to copy this, but it explodes if there are too many of them.
Async-signal-safety of TLS variables is slightly different but related; only the allocation case is actually unsafe, but it's nontrivial to avoid.
- throwawaymaths 2y ago> every access to a TLS variable involves a function call I'm pretty sure I've taken a pointer ref to a threadlocal. How does that work?
- o11c 2y agoThat uses the result of the function directly, rather than dereferencing it. Just like how the glibc `errno` macro works, except that `errno` is special (in several ways) rather than a normal thread-local (which, ironically, would be more efficient).