Document thread_local behavior with foreign-created threads

[eloff]

Location

https://doc.rust-lang.org/std/macro.thread_local.html
https://doc.rust-lang.org/std/thread/struct.LocalKey.html

Summary

Rust can be used as a static or dynamic library in a host process in another language/runtime. The thread_local documentation makes no mention about how foreign threads behave with respect to to thread locals created via LocalKey or the !thread_local macro.

I think it is safe, with one possible exception. I think the const {} syntax allows Rust to avoid lazy initialization and instead use a more efficient implementation that may rely on statically allocated thread-local storage (TLS) instead of dynamically allocated TLS keys. I do not see how this would work with foreign-created threads that call into Rust.

Researching this has proved difficult, I think the docs should clarify the behavior and what is guaranteed and what isn't when it comes to foreign-created threads.

[ChrisDenton]

Rust doesn't really have a runtime to speak of so it can work inside other languages runtimes. With constant values it will use the TLS capabilities of the binary format itself, if supported by the target. So it should work whatever the "host" process.

[eloff]

That's better than I expected, could we document something to that effect for the thread_local crate, that it works regardless of whether Rust creates the threads or not?