Hacker News Reader

Comment by yokohummer7 | Hacker News Reader

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.

View on HN

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.

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.

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).

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.

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.

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.

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.

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.

Reply on news.ycombinator.com