3 ms·

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

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
    It's not clear to me what the alternative would be here. The common case is that the parent calls `join` and handles the result there. This needs to work even if the child thread returns quickly, before `join` is called in the parent. If we switched to a strategy where a panic in the child immediately injected a panic into the parent, or aborted the program, that would break the common case. I don't think there's any way for Rust to know the difference between "the parent is doing some work and hasn't joined yet" and "the parent has no intention of ever joining", if the parent isn't going to be explicit about that.

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
  It's not clear to me what the alternative would be here. The common case is that the parent calls `join` and handles the result there. This needs to work even if the child thread returns quickly, before `join` is called in the parent. If we switched to a strategy where a panic in the child immediately injected a panic into the parent, or aborted the program, that would break the common case. I don't think there's any way for Rust to know the difference between "the parent is doing some work and hasn't joined yet" and "the parent has no intention of ever joining", if the parent isn't going to be explicit about that.