Tokio: Stop runtime on task panic

[mikhailOK]

Version

tokio 0.2.6

Description

I'm indirectly using tokio runtime with basic scheduler (through using actix 0.9.0).
It seems like tokio 0.1 would stop if any task panics, but 0.2.6 catches everything in task::harness::Harness::poll and the runtime keeps going.

Is there any way to get the old behavior of stopping the runtime?

[carllerche]

Are you able to abort on panic? You could also set a panic_handler that signals the root task (block_on) to exit.

[mikhailOK]

panic hook to signal the root task works.
Is there a plan to add API to pass a panic_handler to Harness::poll as opposed to std panic hook?

[Vlad-Shcherbina]

Dealing with it in the panic handler is not the best option because maybe I still want to explicitly catch panics in specific scopes, but unexpected panics elsewhere should terminate the whole thing. By default. It's an unpleasant surprise when they don't (see fail-fast).

[Darksonn]

Closing in favor of #2699.

[Vlad-Shcherbina]

It's not about tests. It's about panics being silently caught everywhere. In production too.

Anywhere else in Rust, if there is a panic in the code not explicitly wrapped in catch_unwind, the whole program terminates with a diagnostic message. This goes in line with Rust's emphasis on correctness. Panic usually indicated a bug in the code, and I don't want bugs to be silently ignored. I want bugs to be reported and fixed.

It is true that sometimes we need to catch panics to ensure robustness. For example, perhaps we don't want a panic in a request handler to terminate the whole web server program. But that's none of tokio's business! It's web framework's or even web application's business! It is possible to use tokio for something besides web applications, and in those use cases panics definitely shouldn't be silently ignored.

Consider reopening.

[Darksonn]

Regarding the "anywhere else in Rust" part, I will note that we are mirroring the behavior of std::thread. See also #1830 and #1879.

[carllerche]

tokio::spawn models thread::spawn. As @Darksonn mentioned, thread::spawn does not abort the process on panic. Spawned tasks are unwind-safe due to the Send + 'static bound.

In order to deviate from thread::spawn's behavior, we would need a compelling argument.

I could buy into a shutdown_on_panic flag to runtime given a compelling argument. One would have to explain why std's behavior is not sufficient (i.e. configure the process to abort on panic).

[s97712]

tokio::spawn models thread::spawn. As @Darksonn mentioned, thread::spawn does not abort the process on panic. Spawned tasks are unwind-safe due to the Send + 'static bound.

In order to deviate from thread::spawn's behavior, we would need a compelling argument.

I could buy into a shutdown_on_panic flag to runtime given a compelling argument. One would have to explain why std's behavior is not sufficient (i.e. configure the process to abort on panic).

What about spawn_local? Whether to consider to end the current thread when panic in the "local task"?

[Darksonn]

I don't think spawn_local and spawn should have _different_ behaviour on this point.

[hawkw]

What about spawn_local? Whether to consider to end the current thread when panic in the "local task"?

I think inconsistent behavior between spawn and spawn_local is not ideal --- it would introduce more complexity and confusion.

I could buy into a shutdown_on_panic flag to runtime given a compelling argument. One would have to explain why std's behavior is not sufficient (i.e. configure the process to abort on panic).

IMO, the main argument for a shutdown_on_panic flag is for test code. If assertions are made in code that ends up being run in a spawned task, the JoinHandles of all those spawned tasks must be awaited in the main test body to ensure panics from assertion failures are propagated. This can be unwieldy, and in some cases, it's easy to misplace a JoinHandle and forget to await it, resulting in a test that passes even if an assertion fails --- which is far from ideal. If there was a shutdown_on_panic flag, I would definitely use it in tests (and might want tokio::test to enable it).

[s97712]

If these tasks are running in the same thread and one of tasks is panic, why the other tasks still working, which makes me more confused.

[Darksonn]

@s97712 Panics in spawned tasks are caught, just like they are for spawned threads in std. Tasks spawned with the ordinary tokio::spawn function also share their threads in some manner.