Rainer Weikusat <rainerweiku...@virginmedia.com> writes:
> John Morris <jmor...@beau.org> 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.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
