TLS in libstd - extending to new OS

[utsavm9]

I am adding support for a new OS target to the Rust compiler. While implementing the thread local storage part of the standard library, I found this:

https://github.com/rust-lang/rust/blob/2c31b45ae878b821975c4ebd94cc1e49f6073fd0/library/std/src/sys/unsupported/thread_local_key.rs#L24

pub fn requires_synchronized_create() -> bool

• From https://github.com/rust-lang/rust/commit/495c998508039764b07a64303ae2c9461ec86a7b, I understand that platforms where Mutex::init() needs to be called after Mutex::new() to use the mutex, those platforms should have requires_synchronized_create() return false.
• Unix-like have this as false while Windows has this as true.

I am not sure what I should look in the OS documentation to determine if requires_synchronized_create should be true or false for the platform I am working on. Any ideas on what I should look for?

[godmar]

From my reading of the code, the lock in the TLS key constructor exists to protect the code that adds destructors to the lock free list that is kept as part of the Rust runtime. This way, if multiple threads call the lazy init function, each key's destructor is added only once. (In Linux, Rust uses the destructor that can be passed to pthread_key_create).

To answer your question - whether you need to return true or false from requires_synchronized_create depends on how your platform implements the key create and destructor function. If it's safe to call the equivalent of pthread_key_create from multiple threads and if the underlying system provides a suitable destructor and if it's safe to call these destructors without deadlocking, then you should return false.

If you need a specially woven implementation for create (like the one adapted for Windows) that's not thread-safe, then you should return true.