Struct std::thread::LocalKey

pub struct LocalKey<T: 'static> { /* fields omitted */ }

A thread local storage key which owns its contents.

This key uses the fastest possible implementation available to it for the target platform. It is instantiated with the thread_local! macro and the primary method is the with method.

The with method yields a reference to the contained value which cannot be sent across threads or escape the given closure.

Initialization and Destruction

Initialization is dynamically performed on the first call to with() within a thread, and values that implement Drop get destructed when a thread exits. Some caveats apply, which are explained below.

Examples

use std::cell::RefCell;
use std::thread;

thread_local!(static FOO: RefCell<u32> = RefCell::new(1));

FOO.with(|f| {
    assert_eq!(*f.borrow(), 1);
    *f.borrow_mut() = 2;
});

// each thread starts out with the initial value of 1
thread::spawn(move|| {
    FOO.with(|f| {
        assert_eq!(*f.borrow(), 1);
        *f.borrow_mut() = 3;
    });
});

// we retain our original value of 2 despite the child thread
FOO.with(|f| {
    assert_eq!(*f.borrow(), 2);
});

Platform-specific behavior

Note that a "best effort" is made to ensure that destructors for types stored in thread local storage are run, but not all platforms can guarantee that destructors will be run for all types in thread local storage. For example, there are a number of known caveats where destructors are not run:

• On Unix systems when pthread-based TLS is being used, destructors willnot be run for TLS values on the main thread when it exits. Note that theapplication will exit immediately after the main thread exits as well.
• On all platforms it's possible for TLS to re-initialize other TLS slotsduring destruction. Some platforms ensure that this cannot happeninfinitely by preventing re-initialization of any slot that has beendestroyed, but not all platforms have this guard. Those platforms that donot guard typically have a synthetic limit after which point no moredestructors are run.
• On macOS, initializing TLS during destruction of other TLS slots cansometimes cancel all destructors for the current thread, whether or notthe slots have already had their destructors run or not.

Methods

impl<T: 'static> LocalKey<T>

fn with<F, R>(&'static self, f: F) -> R where F: FnOnce(&T) -> R

Acquires a reference to the value in this TLS key.

This will lazily initialize the value if this thread has not referenced this key yet.

Panics

This function will panic!() if the key currently has its destructor running, and it may panic if the destructor has previously been run for this thread.

fn state(&'static self) -> LocalKeyState

🔬 This is a nightly-only experimental API. (thread_local_state #27716)

state querying was recently added

Query the current state of this key.

A key is initially in the Uninitialized state whenever a thread starts. It will remain in this state up until the first call to with within a thread has run the initialization expression successfully.

Once the initialization expression succeeds, the key transitions to the Valid state which will guarantee that future calls to with will succeed within the thread.

When a thread exits, each key will be destroyed in turn, and as keys are destroyed they will enter the Destroyed state just before the destructor starts to run. Keys may remain in the Destroyed state after destruction has completed. Keys without destructors (e.g. with types that are Copy), may never enter the Destroyed state.

Keys in the Uninitialized state can be accessed so long as the initialization does not panic. Keys in the Valid state are guaranteed to be able to be accessed. Keys in the Destroyed state will panic on any call to with.

Trait Implementations

impl<T: 'static> Debug for LocalKey<T>

fn fmt(&self, f: &mut Formatter) -> Result

Formats the value using the given formatter.