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.

A LocalKey’s initializer cannot recursively depend on itself, and using a LocalKey in this way will cause the initializer to infinitely recurse on the first call to with.

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
let t = thread::spawn(move|| {
    FOO.with(|f| {
        assert_eq!(*f.borrow(), 1);
        *f.borrow_mut() = 3;
    });
});

// wait for the thread to complete and bail out on panic
t.join().unwrap();

// 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:

1. On Unix systems when pthread-based TLS is being used, destructors will not be run for TLS values on the main thread when it exits. Note that the application will exit immediately after the main thread exits as well.
2. On all platforms it’s possible for TLS to re-initialize other TLS slots during destruction. Some platforms ensure that this cannot happen infinitely by preventing re-initialization of any slot that has been destroyed, but not all platforms have this guard. Those platforms that do not guard typically have a synthetic limit after which point no more destructors are run.
3. When the process exits on Windows systems, TLS destructors may only be run on the thread that causes the process to exit. This is because the other threads may be forcibly terminated.

Synchronization in thread-local destructors

On Windows, synchronization operations (such as JoinHandle::join) in thread local destructors are prone to deadlocks and so should be avoided. This is because the loader lock is held while a destructor is run. The lock is acquired whenever a thread starts or exits or when a DLL is loaded or unloaded. Therefore these events are blocked for as long as a thread local destructor is running.

Implementations

impl<T: 'static> LocalKey<T>

pub 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.

pub fn try_with<F, R>(&'static self, f: F) -> Result<R, AccessError> 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. If the key has been destroyed (which may happen if this is called in a destructor), this function will return an AccessError.

Panics

This function will still panic!() if the key is uninitialized and the key’s initializer panics.

Trait Implementations

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

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

Formats the value using the given formatter.