3 ms·

You say like C/C++ applications are particularly more resilient to OOM situations. That hasn't been my experience. You can deal with OOM in C/C++, but that does

You say like C/C++ applications are particularly more resilient to OOM situations. That hasn't been my experience. You can deal with OOM in C/C++, but that doesn't mean it is quite viable. Even popular C libraries just abort when memory allocation failed. Regarding C++, is there really a code that even tries to capture `bad_alloc`? If so, did they test the various OOM situations that the program may encounter? I highly doubt it. I don't think that the "just panic" strategy used by Rust is pretty. It is mediocre at best. But I also don't think the way C/C++ handle OOM is great. They produce similar results in practice.

mtanski 11y ago
C libraries are worse, esp. the desktop focused ones (glib and all of gnome). Network focused libraries tend to be better (lib libevent / libev), and you see people send patches to fix OOM cases since enough people disable over commit / don't run Linux. In my experience C++ libraries tend to do better because of culture using RAI for everything. And the C++ servers I've worked with most of them had a std::exception handler some where near the top of connection / request handler and deal with it fine. And over the years, the bad_allocs helped us deal with some dumb (but not malicious) clients without going down. In one case the client was essentially causing a multi GB buffering window to happen. I'd be curious if anybody at fb could share their experiences since it seams like they building a lot of stuff using their C++ folly / proxygen libraries.
- yokohummer7 11y ago
  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

C libraries are worse, esp. the desktop focused ones (glib and all of gnome). Network focused libraries tend to be better (lib libevent / libev), and you see people send patches to fix OOM cases since enough people disable over commit / don't run Linux. In my experience C++ libraries tend to do better because of culture using RAI for everything. And the C++ servers I've worked with most of them had a std::exception handler some where near the top of connection / request handler and deal with it fine. And over the years, the bad_allocs helped us deal with some dumb (but not malicious) clients without going down. In one case the client was essentially causing a multi GB buffering window to happen. I'd be curious if anybody at fb could share their experiences since it seams like they building a lot of stuff using their C++ folly / proxygen libraries.

yokohummer7 11y ago
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.