Rainer Weikusat <rainerweikusat@???> writes:

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

[...]

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

[...]

> 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'),
[...]

> This means one gets the 'exit when running out of memory' logic for
> free

[...]

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

Point against this: This is only sensible if the pointer will actually
be dereferenced 'soon' after it was returned by malloc instead of - say
- being stored in a structure and then passed on to a system call (eg,
read) after two days have passed.