I have hit a speedbump in a project I am working on. Basically, I have an Arc<T> cloned object that gets (move) captured in a closure, and that closure gets moved to another thread with thread::spawn. The compiler complains that T needs to be 'static but I don't see why that is necessary, as Arc<T> …

T: 'static means the type T doesn't contains any reference, except the 'static ones. For example, Arc<&'a i32> can't outlive the lifetime 'a even though it's wrapped in Arc.

Note that this in turn is required to be able to safely implement Send and Sync for Arc, which is mainly used for multithreaded situations

Send and Sync are distinct concerns from the lifetime -- Arc<T> only requires T: Send + Sync for both. The 'static requirement comes from the unscoped implementation of std::thread::spawn, but you can use non-'static types perfectly well with rayon, crossbeam scope, etc.

T: 'static means the type T doesn’t contains any reference, except the 'static ones. For example, Arc<&'a i32> can’t outlive the lifetime 'a even though it’s wrapped in Arc. Okay, that makes sense. I think I was getting confused with putting a lifetime parameter on type T with T: 'static thinking…

Why is T 'static constrained when using Arc<T> and thread::spawn

help

sudison March 14, 2019, 8:54am 6

Burned by this issue for a whole day until I saw this thread: Why does thread::spawn need static lifetime for generic bounds?

Topic		Replies	Views
Callback in multithreaded code help	11	1374	May 1, 2020
Lifetime problem when spawning a thread with arc mutex help	3	991	August 13, 2021
Why does thread::spawn need static lifetime for generic bounds? help	8	25714	July 21, 2022
Arc<T> requiring a lifetime for T. Why? help	6	1739	January 3, 2023
[Solved] Why is a `'static` lifetime required here? Moving an owned variable into a thread help	8	2426	January 12, 2023

Why is T 'static constrained when using Arc<T> and thread::spawn

Related topics