How can std::thread::JoinHandle::join catch panics?

Question

The code below compiles only if dyn Fn is UnwindSafe + RefUnwindSafe, because panic::catch_unwind requires it to be able to catch the panic.

use std::panic;
use std::panic::{UnwindSafe, RefUnwindSafe};

fn launch_closure(f: Box<dyn Fn() +  UnwindSafe + RefUnwindSafe>) {
    let result = panic::catch_unwind(|| {
        f();
    });    
}

However, std::thread::JoinHandle::join function is able to catch the panic even if the thread closure is not UnwindSafe + RefUnwindSafe:

If the child thread panics, Err is returned with the parameter given to panic!.

How?

I'd like to be able to know if my closure panicked, but UnwindSafe + RefUnwindSafe is too restrictive, I cannot use CondVar for example.

Playground

Answer 1

thread::spawn wraps the closure in an AssertUnwindSafe to tell the compiler that it knows that the given closure is unwind-safe:

let try_result = panic::catch_unwind(panic::AssertUnwindSafe(|| {
    crate::sys_common::backtrace::__rust_begin_short_backtrace(f)
}));

So, what is unwind safety and how can thread::spawn make that assertion?

From the documentation for UnwindSafe:

In Rust a function can “return” early if it either panics or calls a function which transitively panics. This sort of control flow is not always anticipated, and has the possibility of causing subtle bugs through a combination of two critical components:

1. A data structure is in a temporarily invalid state when the thread panics.
2. This broken invariant is then later observed.

A type is not unwind safe if both of these can be true.

Types like Mutex and RwLock are unwind safe because they use poisoning to protect you from broken invariants. If a panic occurs in another thread that has a lock on a Mutex then it becomes poisoned and you must explicitly call PoisonError::into_inner to access the possibly-inconsistent data. If you cause a bug by making assumptions about a poisoned mutex, then that's your own responsibility and the Rust type system can't help you there.

Mutable references and non-sharable types with interior mutability like RefCell are not unwind safe because they don't offer such protection. However, they are also not Sync, so you can't get into a situation where you use them after another thread has panicked while holding a reference.

The final piece of the puzzle is that thread::spawn creates a new thread stack. That means it can guarantee that the closure is called first in the stack so nothing in the same thread as the closure can access its environment after a panic is caught.

While thread::spawn can't guarantee that the closure is unwind safe in the general case, it knows that:

1. The closure is Send (by its own bounds), so it cannot contain references to non-Sync types.
2. The non-unwind safe types in std (mutable references and cell types) are also not Sync, which means nothing can access a non-unwind safe type from outside the thread
3. Nothing in the same thread as the call to the closure can access its environment after the panic is caught.

So it is safe for the closure to be unwound because there is no possibility of broken invariants being unintentionally observed after a panic.

It is of course possible for a closure to make use of a user-defined type that is not unwind safe but is Sync, in which case this assumption would turn out to be incorrect. However, this would require unsafe code either from a third party crate or by the same author as the closure itself. It is always the responsibility of the author of unsafe code to ensure memory safety. It is not sound for a type to be Sync if a panic in another thread could cause UB. It is up to the author to decide if logical bugs are acceptable, but memory unsafety never is.

---

So... can you use the same trick in your code? Unfortunately, you probably cannot. Since you don't have control over the caller of launch_closure, you can't make the guarantee that a panic won't cause invalid state to be observed by callers in the same thread.