3 ms·

That's interesting, it seems that I'm biased because I've primarily seen desktop-ish libraries. Regarding your usage of `bad_alloc`, I think relaxing the curre

That's interesting, it seems that I'm biased because I've primarily seen desktop-ish libraries. Regarding your usage of `bad_alloc`, I think relaxing the current behavior of aborting will help implement such a behavior. Long-running Rust applications should be resilient to panics anyways, so request handler may regard OOM as just like many other panicking situations. But I have no idea how it would be hard to change Rust's OOM handler to panic. Currently it just aborts.

mtanski 11y ago
While I think this is an important problem to solve, it's not lost on me that this isn't an easy problem to solve. It's complicated further by design decisions like no stack unwinding and current behavior. I'm not sure they can change the current behavior without having a backwards incompatible change. It's also not a unique problem. The Linux guys have been working better handling OOMs in the kernel. There's been some interesting discussions in the last year how to guarantee forward progress in filesystem transactions in the face of OOMs (in the middle of transactions).
- pcwalton 11y ago
  What? Stack unwinding on OOM would not be a backwards incompatible change if it could be made to work (which is no harder than doing it in C++). "Design decisions like no stack unwinding" is a confusing thing to say, given that Rust uses stack unwinding.
  - heinrich5991 11y ago
    The library ecosystem needs to know whether it's allowed to make allocations in destructors. With the current situation, it's no problem, because there's no unwinding on OOM. This is not backward-incompatiblity, but it makes it hard to make unwinding on OOM to something useful.
  - Jweb_Guru 11y ago
    Stack unwinding on OOM can't work properly right now given that stack unwinding can allocate memory. If anything trying to make that catchable locks you into aborting on double panic. It's a bad idea. The correct way to approach this is to design a standard library variant that doesn't assume success on allocation.
    - pcwalton 11y ago
      Sure, I agree that these are challenges, but C++ has exactly the same problem with std::bad_alloc, so I don't see how this is an argument that C++'s approach is better than that of Rust.
      - mtanski 11y ago
        The expected behavior for C++ destructors is pretty well documented. Eg. don't throw in a destructor / don't do things that would throw in a destructor. You're free to try to skirt these rules, but if you get caught that behavior is documented. If you're building an application when you care about std::bad_alloc, you probably know that already.

mtanski 11y ago

While I think this is an important problem to solve, it's not lost on me that this isn't an easy problem to solve. It's complicated further by design decisions like no stack unwinding and current behavior. I'm not sure they can change the current behavior without having a backwards incompatible change. It's also not a unique problem. The Linux guys have been working better handling OOMs in the kernel. There's been some interesting discussions in the last year how to guarantee forward progress in filesystem transactions in the face of OOMs (in the middle of transactions).

pcwalton 11y ago
What? Stack unwinding on OOM would not be a backwards incompatible change if it could be made to work (which is no harder than doing it in C++). "Design decisions like no stack unwinding" is a confusing thing to say, given that Rust uses stack unwinding.
- heinrich5991 11y ago
  The library ecosystem needs to know whether it's allowed to make allocations in destructors. With the current situation, it's no problem, because there's no unwinding on OOM. This is not backward-incompatiblity, but it makes it hard to make unwinding on OOM to something useful.
- Jweb_Guru 11y ago
  Stack unwinding on OOM can't work properly right now given that stack unwinding can allocate memory. If anything trying to make that catchable locks you into aborting on double panic. It's a bad idea. The correct way to approach this is to design a standard library variant that doesn't assume success on allocation.
  - pcwalton 11y ago
    Sure, I agree that these are challenges, but C++ has exactly the same problem with std::bad_alloc, so I don't see how this is an argument that C++'s approach is better than that of Rust.
    - mtanski 11y ago
      The expected behavior for C++ destructors is pretty well documented. Eg. don't throw in a destructor / don't do things that would throw in a destructor. You're free to try to skirt these rules, but if you get caught that behavior is documented. If you're building an application when you care about std::bad_alloc, you probably know that already.