join hangs if a worker thread panics about rayon HOT 6 CLOSED

Yes, I put no effort into error handling at the moment. I was debating between using catch_panic (or whatever we call it now) versus trying to stay on stable Rust.

from rayon.

The other place that panic handling is totally wrong is in the parallel iterator stuff, which fails to drop partially completed results (though technically that is not illegal).

from rayon.

So basically the "stable Rust" option I was debating about would be similar to what you suggest -- use poisoning to poison latches as we unwind, and then have the top-level code bring up another thread to replace the one that was torn down (or perhaps just tear them all down and start things back up). But I'd like to have some notion of how targeted the propagation is -- the strategy I just described seems like a panic in one place could randomly affect other workers.

from rayon.

With stealing, a thread's unwind stack could even have a mix of completely distinct jobs, right? I'm not sure there's really any reasonable panic recovery in that case. I'm only hoping for naive panic propagation as a base case -- let the whole process die rather than hang.

from rayon.

There is a pretty sensible solution to this, which is to catch any panics that occurs while executing a job, send the Box back to the caller of join(), and then re-throw the panic there. This effectively makes the result type of a job Result<T, Box<Any>>. However this requires panic::recover, which isn't stable, and panic::propagate, which hasn't landed yet (rust-lang/rust#30557).

from rayon.

@Amanieu yeah, the main question is whether to just make rayon rely on panic::recover (and hence require nightly), or not. I think I'd rather just do something sensible, as @cuviper suggests, and adopt recover later when things have stabilized (or perhaps under #[cfg(nightly)] switch).

from rayon.