5 ms·

I don't understand the announcement on panics. Hasn't it always been the case that thread boundaries (via spawn) could contain panics? It's also used to have t

I don't understand the announcement on panics. Hasn't it always been the case that thread boundaries (via spawn) could contain panics? It's also used to have the incorrect default that such panics were silently ignored. .NET made this same mistake: background threads could silently die. They reversed and made a breaking change so any uncaught exception kills the process. I'd imagine Rust will do so by encouraging a different API if they haven't already. (I opened an RFC on this last year, but I didn't understand enough Rust and made a mess of it. But still a great experience, speaking to the very kind and professional community. In particular several people were patient, but firm, in explaining my misunderstandings.)

steveklabnik 10y ago
> Hasn't it always been the case that thread boundaries (via spawn) > could contain panics? Yes. This lets you catch an unwinding panic from inside the thread itself, rather than observing it get killed from the outside. In Rust, they're not silently ignored: `join()` returns a `Result`, which has a `must_use` attribute, which will warn if you don't do something with it.
- MichaelGG 10y ago
  Thanks for the clarification. On thread panics: Suppose you have a long-running thread that's updating shared variable. You don't call join on it; just drop it, so it's detached, running in the background. If that thread crashes (and isn't in e.g. a mutex so it can't poison), your process will continue on in an invalid state. Yes, you could add code to notice the panic and abort the process, but by default, it'll silently fail, right?
  - steveklabnik 10y ago
    > and isn't in eg a mutex so it can't poison Well, Rust makes sure that you have _some_ kind of concurrency primitive in place to make this safe. It's also worth mentioning that Rust is concerned about preventing memory safety bugs, not every single kind of bug ever. I mean, we want to encourage robust code, but we don't make the claim that Rust solves every kind of bug possible with the type system.
    - MichaelGG 10y ago
      I understand. It just seems like a very odd default, allowing threads to silently crash. Is there ever a good scenario for this? Flip it around: if the default was thread crash->panic, would any users be upset? Are there people intentionally depending on silent panics? It is the opposite of robust, more toward "on error resume next", to be rude. Just feels like an odd choice, that's all. Edit: As an example: Suppose a background thread opens a file and writes out its pid and date every minute. If there's any panic on that thread, then the process will just go on, oblivious to the error. I find it hard to believe that's remotely close to the majority of intentions when spawning a detached background thread. For the few cases when you want "fire-and-forget-and-don't-care-if-it-fails", explicitly stating so seems wise.
      - steveklabnik 10y ago
        Yes, one of the reasons that catching panics was even stabilized in the first place is because in many scenarios, aborts are not acceptable. Embedding Rust in other languages and runtimes is an important use case, for example, and a bug in your Rust extension bringing down your whole Rails app is not great. The idea is not to make panics silent, but to be able to go from "this process is crashing" to "here's an error code".
        ori_b 10y ago
        > Embedding Rust in other languages and runtimes is an important use case, for example, and a bug in your Rust extension bringing down your whole Rails app is not great. It's not, but it beats it silently ending up in a bad state.
        kibwen 10y ago
        The failure case in mind here is not silent data corruption, it is merely having your in-process performance monitoring service go offline.
      - oconnor663 10y ago

steveklabnik 10y ago

> Hasn't it always been the case that thread boundaries (via spawn) > could contain panics? Yes. This lets you catch an unwinding panic from inside the thread itself, rather than observing it get killed from the outside. In Rust, they're not silently ignored: `join()` returns a `Result`, which has a `must_use` attribute, which will warn if you don't do something with it.

MichaelGG 10y ago
Thanks for the clarification. On thread panics: Suppose you have a long-running thread that's updating shared variable. You don't call join on it; just drop it, so it's detached, running in the background. If that thread crashes (and isn't in e.g. a mutex so it can't poison), your process will continue on in an invalid state. Yes, you could add code to notice the panic and abort the process, but by default, it'll silently fail, right?
- steveklabnik 10y ago
  > and isn't in eg a mutex so it can't poison Well, Rust makes sure that you have _some_ kind of concurrency primitive in place to make this safe. It's also worth mentioning that Rust is concerned about preventing memory safety bugs, not every single kind of bug ever. I mean, we want to encourage robust code, but we don't make the claim that Rust solves every kind of bug possible with the type system.
  - MichaelGG 10y ago
    I understand. It just seems like a very odd default, allowing threads to silently crash. Is there ever a good scenario for this? Flip it around: if the default was thread crash->panic, would any users be upset? Are there people intentionally depending on silent panics? It is the opposite of robust, more toward "on error resume next", to be rude. Just feels like an odd choice, that's all. Edit: As an example: Suppose a background thread opens a file and writes out its pid and date every minute. If there's any panic on that thread, then the process will just go on, oblivious to the error. I find it hard to believe that's remotely close to the majority of intentions when spawning a detached background thread. For the few cases when you want "fire-and-forget-and-don't-care-if-it-fails", explicitly stating so seems wise.
    - steveklabnik 10y ago
      Yes, one of the reasons that catching panics was even stabilized in the first place is because in many scenarios, aborts are not acceptable. Embedding Rust in other languages and runtimes is an important use case, for example, and a bug in your Rust extension bringing down your whole Rails app is not great. The idea is not to make panics silent, but to be able to go from "this process is crashing" to "here's an error code".
      - ori_b 10y ago
        > Embedding Rust in other languages and runtimes is an important use case, for example, and a bug in your Rust extension bringing down your whole Rails app is not great. It's not, but it beats it silently ending up in a bad state.
        kibwen 10y ago
        The failure case in mind here is not silent data corruption, it is merely having your in-process performance monitoring service go offline.
    - oconnor663 10y ago