John Morris <jmorris@???> writes:
> On Wed, 2016-05-04 at 21:41 +0100, Arnt Gulbrandsen wrote:
>> Malloc() is very simple: You ask for memory and get it. The negative
>> side
>> of that simplicity is that if you're out of memory (and that happens
>> occasionally if a server is run close to capacity) then processes die
>> and/or become unresponsive. Such is the tyranny of the Poisson
>> distribution.
>
> Not a problem at all. An API is a contract, violate it at your peril.
> The malloc() call's contract is you request memory with the
> understanding that "no" is a legal answer.

[...]

> On the other hand, a tactic of simply allowing the process that hits
> the memory limit to die, thus freeing up some memory, might be the
> winning move.

[...]

> After all, wrapping malloc in a simple test for NULL and exit beats
> just assuming any malloc will succeed.

The idea was not "just assuming that it will succeed" but that malloc
will return a null pointer if it failed. In a usual UNIX(*) application,
derefencing a null pointer causes the process which did it to be
terminated by a SIGSEGV ('signal 11'), possible with a core dump in case
post-mortem inspection of the situation is desired. This means one gets
the 'exit when running out of memory' logic for free and even with
better options for looking into the issue after the fact than can be
reimplemented easily.

I'm dealing with a program where every allocation failure is
meticolously passed up the call stack so that the top-most function can
then cause the process to terminate and I've just recently decided that
this is completley useless and that I want to get a message what failed,
followed by program termination close to the point of failure
instead. Using a null pointer deref to this effect is an IMHO clever
idea I didn't think of so far.

NB: I'm not yet convinced that I'll end up using it but it's surely
something to consider.