Main thread shouldn't panic when child threads panic

[gsingh93]

When running the following code, the panic in the child thread causes the server to crash:

extern crate hyper;

use hyper::Server;
use hyper::server::Request;
use hyper::server::Response;
use hyper::net::Fresh;

fn panic(_: Request, _: Response<Fresh>) {
    panic!("test")
}

fn main() {
    Server::http(panic).listen("127.0.0.1:3000").unwrap();
}

Here is the output:

thread '<unnamed>' panicked at 'test', src/main.rs:11
thread '<unnamed>' panicked at 'child thread None panicked', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/thread/mod.rs:715
thread '<main>' panicked at 'child thread None panicked', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/thread/mod.rs:715
An unknown error occurred

To learn more, run the command again with --verbose.

This is a fairly serious reliability issue, as a server should never go down because of its child threads.

[reem]

This is due to some new bubbling behavior with join guards.

[seanmonstar]

Specifically, I see that scoped threads join will panic, where spawned threads join returns a Result.

[e-oz]

I'm not sure if it's a hyper's issue, but maybe somebody will be kind enough to show code how to catch that Poisoning Error? Would be awesome to kill just one thread and let others work. Or terminate, at least, to let monitoring know server needs to be restarted.

[seanmonstar]

What do you mean? This issue should be fixed. Is another panic occurring?

On Mon, Dec 7, 2015, 1:49 PM Evgeniy OZ notifications@github.com wrote:

I'm not sure if it's hyper's issue,but maybe somebody will be kind enough
to show code how to catch that Poisoning Error? Would be awesome to kill
just one thread and let others to work. Or terminate, at least.

—
Reply to this email directly or view it on GitHub
#447 (comment).

[e-oz]

I'm sure issue is fixed and I just don't understand something. My experience with Rust is very small - about month.
Currently my issue is: when some thread panic, all other threads (in Iron) became useless - I can't lock Arc<Mutex> anymore. I can catch it but I can't do anything useful except send 503 response to user. Good solution would automatically "restart" thread - kill poisoned thread, instantiate new mutex for resource object. Or, if it's not possible - just ask main thread to die, to let monitoring daemon restart server.

[Ryman]

@e-oz See the second example here, under "To recover from a poisoned mutex": http://doc.rust-lang.org/std/sync/struct.Mutex.html#examples