Hello!
I’m having some issues with threadpool where I have some threads hanging after a panic and looking for ways to handle that. I’ve been looking at the std::panic hooks. However, I’m having some issues because my workers have some parameters which are not std::panic::UnwindSafe, such as mpsc's senders.
So, what’s the best way to handle panics that happen inside of a thread when using the threadpool crate?
For the record, what I’m currently doing is joining the threadpool and checking it’s panic_count() after. But I don’t feel completely fine with that.
This is a good question!
mpsc::Sender is !UnwindSafe because it has an UnsafeCell inside, which explicitly says it’s !RefUnwindSafe. What I find interesting, however, is that mpsc::SyncSender is Unwindsafe. So one option might be to switch to sync_channel() (might be a good idea for backpressure/resource utilization purposes anyway).
It’s not immediately clear to me (I’ve not examined the code and unwind safety) whether mpsc::Sender<T>, where T: UnwindSafe, can be safely asserted to be AssertUnwindSafe.
Crash out of the program and restart. (Saving panic stack trace, to fix the bug. If editing files, maybe dump a write to new copies that can then be independently checked for corruption.)
It is best way to get bugs fixed and not to cover up state invalidation that can lead to corrupt data.
Exception Safety is very hard.
You are practically guaranteed any substantial code that has not been written and reviewed to offer some exception safety will misbehave after.