Lifetime troubles sharing references between threads

by

A great thing about Rust is that the type-checking across functions is done solely by the function signature. That means you can replace most of the bodies of functions with unimplemented!() and preserve type-checking errors.

Repeat that process a few times, and you end up not calling a lot of functions – remove those. Inlining modules and reducing structs / enums can also help.

At some point your error will disappear – the first clue towards the problem! Keep at it, and you get a tiny reproduction:

use std::sync::{Arc, Mutex};
use std::thread;

pub enum MasterSocketList<'a> {
    One(&'a u8),
}

pub struct Slot;

impl Slot {
    pub fn new<'a>(master_socket_list: Arc<Mutex<MasterSocketList<'a>>>) -> Slot {
        thread::spawn(move || {
            master_socket_list;
        });
        unimplemented!();
    }
}

fn main() {}

Checking out the error, it still matches:

error[E0477]: the type `[closure@src/main.rs:12:23: 14:10 master_socket_list:std::sync::Arc<std::sync::Mutex<MasterSocketList<'a>>>]` does not fulfill the required lifetime
  --> src/main.rs:12:9
   |
12 |         thread::spawn(move || {
   |         ^^^^^^^^^^^^^
   |
   = note: type must satisfy the static lifetime

Let’s check the docs for the signature of thread::spawn:

pub fn spawn<F, T>(f: F) -> JoinHandle<T>
where
    F: FnOnce() -> T,
    F: Send + 'static,
    T: Send + 'static,

The key point here is F: Send + 'static – the closure you give to spawn must only contain references that last the entire life of the program. This is because spawn can create threads that become detached. Once detached, the thread could live forever, so all references must live at least that long, otherwise you’d get dangling references, a bad thing! Rust saves the day, once again!

If you want to guarantee that the threads will terminate at a known point, you can use scoped threads, such as those provided by scoped-threadpool or crossbeam.

If your code didn’t have a variable with a lifetime inside of it, using some type of shared ownership like Arc paired with something that will ensure only one thread can mutate the variable, like Mutex would have been sufficient. This allows each thread to own the shared value, finally dropping it whenever the last thread exits. See How do I share a mutable object between threads? for details.

More Related Contents:

  1. Why can’t I store a value and a reference to that value in the same struct?
  2. What are non-lexical lifetimes?
  3. The compiler suggests I add a ‘static lifetime because the parameter type may not live long enough, but I don’t think that’s what I want
  4. How can I create my own data structure with an iterator that returns mutable references?
  5. Lifetime error when creating a function that returns a value implementing serde::Deserialize
  6. Why does linking lifetimes matter only with mutable references?
  7. Why is adding a lifetime to a trait with the plus operator (Iterator + ‘a) needed?
  8. Cannot infer an appropriate lifetime for autoref due to conflicting requirements
  9. When is it useful to define multiple lifetimes in a struct?
  10. Moved variable still borrowing after calling `drop`?
  11. What is lifetime elision in very simple terms?
  12. “borrowed value does not live long enough” when using the builder pattern
  13. How can this instance seemingly outlive its own parameter lifetime?
  14. How do I specify lifetime parameters in an associated type?
  15. How to operate on 2 mutable slices of a Rust array?
  16. When returning the outcome of consuming a StdinLock, why was the borrow to stdin retained?
  17. Why does my variable not live long enough?
  18. Why is the bound `T: ‘a` required in order to store a reference `&’a T`?
  19. Sharing a struct with trait objects as properties across threads
  20. Why can’t I return an &str value generated from a String?
  21. Type mismatches resolving a closure that takes arguments by reference
  22. How to fix lifetime error when function returns a serde Deserialize type?
  23. Why does Rust disallow mutable aliasing?
  24. Extend lifetime of variable
  25. Why does the Rust compiler request I constrain a generic type parameter’s lifetime (error E0309)?
  26. Conditionally iterate over one of several possible iterators
  27. Iterator returning items by reference, lifetime issue
  28. Why is the mutable reference not moved here?
  29. How do I use static lifetimes with threads?
  30. How can I create a function with a variable number of arguments?

Leave a Comment