Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atomic types don't implement RefUnwindSafe #37136

Closed
tomaka opened this issue Oct 13, 2016 · 3 comments
Closed

Atomic types don't implement RefUnwindSafe #37136

tomaka opened this issue Oct 13, 2016 · 3 comments

Comments

@tomaka
Copy link
Contributor

tomaka commented Oct 13, 2016

They probably should.

@tomaka
Copy link
Contributor Author

tomaka commented Oct 15, 2016

Hmm, actually I'm no longer sure.

The reason why Mutex and RwLock implement RefUnwindSafe is because of their poisoning mechanism.

If we take for example struct Foo { a: AtomicUsize, b: AtomicUsize } which, as a semantic rule, must always have a and b have the same value, then that struct is not automatically unwind safe. It would be unwind-safe if it used Mutexes, as the mutex would become poisoned.

@alexcrichton
Copy link
Member

The way I personally think about panic safety is that a rule of thumb is that if you can get past thread::spawn then you're panic safe. Put another way, if a type implements both Send and 'static then it is defacto panic safe as it can already cross a panic boundary (thread::spawn).

We would have impl<T: Send + 'static> UnwindSafe for T but coherence runs afoul there unfortunately. If specialization is stabilized then we'd consider this for specialization I believe, however.

@glaebhoerl
Copy link
Contributor

This doesn't seem right to me? Per the docs:

The general idea is that any mutable state which can be shared across catch_unwind is not unwind safe by default.

Atomics fit that description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants