Hacker News Reader

Comment by yokohummer7 | Hacker News Reader

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.

View on HN

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