Lets say I've a number of threads where one of them panics regularly (lost network connection, whatever) but this should not exit the whole program. Instead I want to try again and restart the panicked thread (a bit like Erlang's let it crash philosophy).
I've created an example playpen with a main thread that manages a vector of JoinHandles. The problem here is, that the join operation is blocking and therefore the main thread waits for the first handle, that the iterator returns to finish, but in the meantime panics another thread and crashes the program.
What is the right common way to manage this in Rust?
PS: Maybe I could try to not panic in the thread, but let's assume that this is not possible.
1 Like
You should definitely do that. "lost network connection" should bubble up by returning Result from the functions used in your thread. Panics are reserved for unrecoverable errors and bugs.
playpen showing an example
1 Like
I think the issue is nuanced, especially for safety critical systems. It can be much easier to reason about handling a crashed thread (or closure) than to check the handling of each Result outcome.
For example, restarting a thread might exercise will-trodden startup code, whereas Result error recovery gets run much less frequently.
Thanks, the playpen demo made it clear!
I'm sorry but I don't understand this. Is this a typo and you meant well-trodden, like well hung?
1 Like
Sorry, yes, well-trodden. I meant 'used often'.