On Tue, 21 Mar 2000 11:17:25 -0600 (CST), you wrote:
>On Tue, 21 Mar 2000, Horst von Brand wrote:
>
>> Brian Hurt <bhurt@talkware.net> said:
>> > One thing I find disturbing about this whole debate is the assumption that
>> > the only valid response a program can make to running out of memory is to
>> > crash- and that it doesn't matter if the crash is a SEGV or a more
>> > controlled cleanup & exit.
>>
>> Very few programs do controlled cleanup & exit today, those that do will do
>> so regardless. And if they run OOM (due to overcommitment that can't be
>> met, user quota, rlimit, system isn't overallocating and ran out, or
>> whatever), they won't be able to do anything much about it anyway.
>
>Most programs suck: they're written by programmers who, due to ignorance
>or lack of time, don't check for errors they should. The fact that brk(),
>sbrk(), and malloc() all can return errors is irrelevent- they aren't
>checked. Is this an excuse to not return an error value? Even something
>as simple as popping up a dialog box (which CAN be done- WindowMaker does
>it) instead of simply dying quietly (and leaving a core file behind- the
>default behavior of SIGSEGV) improves the user experience enormously.
Certainly, changing malloc() so it, in Java parlance, "raises an
exception" (i.e. signals the process "something's gone pearshaped
here") would help. The number of apps which call malloc(), get zero,
then try reading from or writing to their nice new buffer at address
0...
Handling one signal is a lot easier than checking every single return
value from every single call, which is what you would need to handle
OOM properly otherwise...
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:34 EST