Hacker News Reader

The problem is the Thread object can be forgotten such that it's never dropped. This would cause the thread to never be joined. This becomes a problem if the thread is borrowing anything from the stack since the borrow could then outlive the stack frame.

View on HN

What happens if you borrow a more complex mutable object to a thread and this thread is killed somehow leaving the borrowed object in a corrupt state, e.g because the thread was killed while doing an unsafe operation on the borrowed object. Can't I catch_unwind the scope call and then access the corrupted object?

Unwind safety is an underdeveloped aspect of rust. Unwinding is not meant to be used for control flow. catch_unwind should be used to protect FFI callbacks and restart unwinding on the other side. I would consider its use in thread pools to be an abuse of the feature.

That said, given that unwinding does exist, it is the responsibility of unsafe code blocks to account for it. They must not allow safe code to create UB. That they mostly don't account for it is a culture issue.

Reply on news.ycombinator.com