The thread boundary restriction for catching panics was lifted quite a while ago with std::panic::catch_unwind: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

Do note the caveats in the docs though. It isn't guaranteed to catch all panics. Indeed, unwinding can be disabled completely with a compiler option (instead, panics will abort).

AFAIK, some Rust types are checked at runtime. For example, RefCell:

"Because RefCell<T> allows mutable borrows checked at runtime, you can mutate the value inside the RefCell<T> even when the RefCell<T> is immutable."

*source https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

EDIT: Sorry, I don't mean 'runtime type checks' are slowing down Rust, but rather that Rust performs more general runtime safety checks (like RefCell).

That isn't "type checking", that is just a guard to prevent simultaneous writes to the same data.

You're correct- what I had meant to say is Rust is smarter with more runtime checks over C for several cases, like RefCell. Therefor, Rust can be slower than C because of safety (but not because of type checking itself).

RefCell has an internal semaphore. It's used specifically for multi threaded scenarios.

If someone is writing a multi threaded C app, they will likely be using semaphores as well. At least, they should be. Rust just enforces it.

So, I wouldn't say rust is "slower" in the regard.

Iirc RefCell is marked !Sync, I thought Mutex was the multithreadong analog?

That's correct.