Panicking tasks should abort process if not handled

RFC for issue opened here: https://github.com/rust-lang/rust/issues/19610

Oh I understand. But then it proves my point that poisoning is not enough to prevent the issue I describe, where one task panics and is no longer doing what it should making the shared state, while not inconsistent, to be potentially incorrect.

From: Daniel Micay [mailto:notifications@github.com]
Sent: Sunday, December 14, 2014 00:05
To: rust-lang/rfcs
Cc: Michael Giagnocavo
Subject: Re: [rfcs] Panicking tasks should abort process if not handled (#519)


In 0000-panic-default-abort.md<https://github.com/rust-lang/rfcs/pull/519#discussion-diff-21794283>:

> @@ -0,0 +1,63 @@

> +- Start Date: 2014-12-12

> +- RFC PR: (leave this empty)

> +- Rust Issue: (leave this empty)

> +

> +# Summary

> +

> +Currently, a spawned task that panics does not abort the process. A panic on a task is simply silently discarded. This is inappropriate behaviour, as the user's program may not be in a desired working state (a sort of zombie process). Instead, failing tasks should fail the entire process unless explicitly opted out of.

> +

> +# Motivation

> +

> +Defaulting to abort improves Rust's correctness, as programmers will have a harder time "forgetting" to handle panics from other tasks. Other systems, such as the Microsoft .NET platform, made the same mistake of silently ignoring background exceptions. For version 2, they made a breaking change to fix this behaviour, presumably because swallowing errors led to buggy programs.

> +

> +Changing this also makes Rust's behaviour more uniform. Having a task abort only if it panics twice, but silently ignore if it only panics once does not seem very elegant.

> +

> +Rust can rely on poisoning to abort related tasks. This allows, say, tasks sharing a mutex to all panic when acquiring the mutex after one task has panicked. This may eventually cause the entire program to crash. Relying on this behaviour may be somewhat non-deterministic, and also relies on every shared struct to support poisoning. This is complementary behaviour, but a: should be opt-in, in the case of a program being unwind-safe and wanting to continue to use the e.g. mutex after a panic, b: does not replace the need for the default behaviour to abort.

I promise I'm not trying to be obtuse or difficult. But AtomicPtr can take arbitrary types, can it not?

It doesn't provide mutable access to arbitrary data. It allows mutation of a pointer. There is never a transaction that can be interrupted part of the way through. The mutex types are only poisoned if a panic happens while the lock is held.

—
Reply to this email directly or view it on GitHub<https://github.com/rust-lang/rfcs/pull/519/files#r21794283>.