Understanding Closure Is Not Send Event Though Captures Send Variables in Rust

A closure in Rust is not automatically Send even if it captures variables that implement Send. The compiler requires the closure itself to guarantee thread safety by ensuring all captured state can be safely transferred across thread boundaries. This distinction prevents data races when closures are executed on different threads, maintaining Rust’s memory safety guarantees without requiring explicit synchronization for every capture.

Understanding the Send Trait

The Send trait is a fundamental marker in Rust that indicates a type’s ownership can be safely transferred from one thread to another. If a type implements Send, it means there are no interior mutabilities or shared references that could lead to data races when moved. Most primitive types like integers and strings are Send. However, raw pointers and certain smart pointers like Rc<T> are not, because they rely on reference counting which is not thread-safe by default. When you spawn a thread using std::thread::spawn, the closure passed to it must be both Send and 'static. The 'static bound ensures the data does not borrow from any local scope that might disappear before the thread finishes.

Why Capturing Send Variables Is Not Enough

It is a common misconception that if a closure only captures variables that are individually Send, the closure itself will be Send. This is incorrect. The closure’s implementation of Send depends on how those variables are captured: by value, by mutable reference, or by immutable reference. When a closure captures a variable by immutable reference (&T), the closure holds a pointer to data owned elsewhere. Even if T is Send, the reference itself is not necessarily safe to send to another thread because the original owner might drop the data while the thread is still reading it. This creates a dangling pointer risk. Similarly, capturing by mutable reference (&mut T) is never Send because multiple threads cannot safely hold mutable access to the same data simultaneously. Only captures by value (moving ownership into the closure) guarantee that the closure owns its data exclusively, allowing it to be sent to another thread safely. Consider this example where the code fails to compile:

use std::thread;

fn main() {
    let data = vec![1, 2, 3];
    // This will fail because 'data' is borrowed immutably
    let handle = thread::spawn(|| {
        println!("{:?}", data);
    });
    handle.join().unwrap();
}

The compiler error occurs because the closure captures data by reference. To fix this, you must move ownership into the closure:

let handle = thread::spawn(move || {
    println!("{:?}", data);
});

By adding move, the closure takes ownership of data. Since Vec<i32> is Send, the closure becomes Send as well.

The Role of the Move Keyword

The move keyword forces the closure to take ownership of all captured variables. This is often necessary when working with threads. Without move, Rust infers the capture mode based on usage. If you only read a variable, it might capture by reference. If you write to it, it might capture by mutable reference. Both reference-based captures prevent the closure from being Send. Using move explicitly tells the compiler to convert all captures into owned values, satisfying the Send requirement provided the underlying types are indeed Send. For more complex scenarios involving associated types and vector manipulation, understanding how traits interact with closures is crucial. You can explore related concepts in Understanding makeVector Trait Associated Type in Rust. This helps clarify how generic constraints apply to closure signatures and their ability to transfer state.

Common Pitfalls and Solutions

One frequent issue arises when trying to share state between threads using Arc<Mutex<T>>. While Arc<T> is Send if T is Send, and Mutex<T> is Send if T is Send, the combination allows safe sharing. However, the closure must still own the Arc to be Send. Cloning the Arc inside the closure before moving it is the standard pattern. Another pitfall involves closures that capture non-Send types indirectly. For instance, if a closure captures a struct that contains an Rc<T>, the closure itself becomes non-Send, even if the rest of the struct is composed of Send types. The compiler checks the entire captured environment recursively. To resolve this, replace Rc with Arc or restructure the data so that non-Send parts remain in the main thread and are accessed via channels instead of direct closure captures. If you are dealing with C++ interop or mixed-language projects, note that Rust's rules differ significantly from C++ move semantics. Understanding these differences is vital for systems programming. See Understanding Move Constructors and R-Value References in C++: A Tech Support Guide for comparative insights.

Conclusion

The key takeaway is that closure capture mode dictates thread safety. Always prefer moving ownership into closures when sending them to threads. Use move explicitly to avoid ambiguity. Check the Send status of all captured types, including nested fields within structs. By adhering to these principles, you ensure your concurrent Rust code remains robust and free from data races.

Frequently Asked Questions

Can I send a closure that captures a Rc?

No, closures capturing Rc<T> are not Send because Rc is not thread-safe. You must use Arc<T> instead, which provides atomic reference counting suitable for multi-threaded environments.

What happens if I don't use move but the closure doesn't mutate the variable?

If the closure only reads the variable, Rust may capture it by immutable reference. This makes the closure non-Send because the reference might dangle if the original owner drops the data. You should still use move to take ownership and ensure safety.

Is a closure that captures nothing Send?

Yes, a closure that captures no external state is trivially Send because it has no dependencies on outside resources that could become invalid or race-conditioned during thread execution.

How do I check if my closure is Send?

You can force the compiler to verify this by assigning the closure to a variable typed as Box. If the compilation succeeds, your closure is Send. Otherwise, the error message will specify which captured variable breaks the trait bound.

Does std::sync::Mutex make a closure Send?

Using Mutex inside a closure does not automatically make the closure Send. The closure must still own the mutex or a clone of an Arc<Mutex>. The mutex protects the data inside, but the ownership transfer of the mutex itself must be safe.