Hacker News Reader

Comment by metadat | Hacker News Reader

Is it really worth worrying about? This strikes me as pedantic. Once a program can no longer allocate memory, it's very likely toast anyway.

Edit: @naasking, all good points. Still, isn't the general strategy to ensure memory isn't exhausted, rather than handling such a situation "gracefully", whatever that means? :)

View on HN

It depends what your program is for. Some programs need guarantees because of bounded resources, so you may want resource allocation to be a visible effect (like embedded systems), or because you're running potentially untrusted code (like JS or WASM in a browser), or because you want sane failure handling (like running modules in a web server).

Graceful is a misnomer, but there are better versions. If you are day, a database server, and you run out of memory and die horribly, availability for all clients is compromised. If you begin rejecting queries or connections until memory js available at least some availability is maintained.

I don't follow, it seems like you're still be hosed in this scenario. What's the difference of stopping accepting connections and rejecting queries vs crashing out? Meaningful work cannot make progress when a busy dynamic system is OOM -- which a database is a prime example of.

Best to avoid the condition, or design the client side to handle the possibility the resource could be unavailable.

Reply on news.ycombinator.com