Struct std::thread::LocalKey
[−]
[src]
pub struct LocalKey<T: 'static> { // some fields omitted }1.0.0
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 support destructors which will be run when a
thread exits.
Examples
fn main() { 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); }); }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 gurantee 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 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.
- 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.
- On OSX, initializing TLS during destruction of other TLS slots can sometimes cancel all destructors for the current thread, whether or not the 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
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
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
.