Fast thread locals: TLS model

language design
#1

As a follow-up on https://internals.rust-lang.org/t/request-for-prioritization-fast-thread-locals/13982:

AIUI (perhaps I'm wrong?) the newly stabilized const initializers make it possible to have faster thread locals by eliminating initialization checks on every call (though it's not documented except in release notes). That still leaves how thread locals are implemented as a potential speed up.

Given the stable existence of const-initialized thread locals, is stabilization of tls_model - The Rust Unstable Book now viable?

In my case, I'm working on a .so library that is only ever ld-preloaded, so initial-exec mode is sufficient, and thread locals are in the hot path. So far I've been relying on cross-language LTO with C code, and leaving thread locals in C, but that's annoying and sometimes too limiting, especially with complex logic. I'd rather not have to write C!

2 Likes
#2

One issue with stabilizing -Ztls-model as-is is that it's rather platform specific, only applying to platforms that use ELF-style TLS. This isn't a deal-breaker by any means, but means that in the future if we wanted to stabilize similar things for other platforms, it might be somewhat problematic.

#3

Using the wrong -Ztls-model is also UB. For example rustc uses initial-exec as tls model (just like you want to use) which forbids dlopen and instead requires the executable to directly depend on librustc_driver.so. Opening it using dlopen may work in some cases, but crash in others.

#4

Maybe could do -C tls-model=linux-glibc=initial-exec?