Hi,

anon (anon.delete@this.b.c) on January 12, 2020 11:30 am wrote:
> Brendan (btrotter.delete@this.gmail.com) on January 11, 2020 10:15 pm wrote:
> > From a process' perspective (or a programmer's perspective); there's a huge difference between random
> > unexpected failure and (e.g.) "mmap()" returning an error that lets you free some virtual memory you
> > were using elsewhere (e.g. for internally caching stuff) and retry (and maybe succeed), or lets you support
> > "partial failure" (where one piece of work is aborted but all other work continues), or at least inform
> > the user/log the problem so the user doesn't assume your software is a buggy piece of crap.
> >
> > Of course for some languages (e.g. Java) the language itself prevents you from writing
> > code that is able to adequately handle "out of memory" conditions (but even in that
> > case the virtual machine might respond by doing garbage collection).
>
> Even if you write your own code extremely carefully, unless you a programming in an embedded context
> where you wrote all the code running on the platform, you can be pretty damn certain there is a
> lot of other parts in your system that are not able to gracefully handle OOM. There are just no
> server or desktop platforms in widespread use that can deal with OOM. It's entirely possible that
> your program sucks up all the memory, and then OOM is triggered by some crucial background service
> that nothing can live without, and which does not have viable alternatives to allocating.
>
> It's because of this that the sane option for desktop or server is to just ignore OOM and
> pretend it doesn't exist. Just hardening your own software is the worst kind of idiocy
> -- it's a massive waste of time, and it doesn't actually protect you from anything.

This kind of thinking is the reason why the world sucks ("Some software is shit, therefore all software should be forced to be shit forever and nobody should ever try to make software better").

- Brendan