Out Of Memory - A caring malloc?
One major problem with all the OOM handling ideas are they are hostile. They assume the situation is out of control and desperate.
What the programmers need is help to avoid getting the user into such dire straits. Consider two scenarios....
* Nibbled to Death by Ducks. The program is malloc'ing many tiny chunks of memory. Eventually it starts thrashing. A quarter of an hour later it runs out of memory and malloc returns 0 or some friendly OOM killer hits it on the head. Assume the OOM killer doesn't, what can the programmer do? Pop up a friendly dialog box, and shutdown neatly? Nah! Not enough memory to do that!
* Grabbing a large chunk. I was using Ghost View. For various reasons it asked for a huge amount of memory. Malloc didn't return zero, there was enough swap. However, the system turned to sticky mud and stayed that way until I could kill the X server 15 minutes later...
Now assume that these two programs are written by responsible, caring programmers. What could they have done to stop entering this domain? Nothing. The OS hates users.
Now if the OS had a "memory getting low, system getting slow" signal, and could send that signal to all programs. Then in the Nibble to Death by Ducks scenario the programmer could start bailing out in a clean and friendly manner.
If the OS had a "malloc, but not at the cost of the system" malloc, then any programmer knows when he is going to be grabbing a really large chunk. So when he grabs a large chunk he uses the "friendly caring malloc" and checks the return code. If the answer is bad, he pops up a friendly message that tells the user that he really doesn't want to do that and why. The user may at his own choice and peril say "do so anyway".
I'm sure the friendly caring malloc could be written in userland, any hints?
The "memory getting low, system getting slow" signal needs some OS support I think.
Any suggestions on how to go about this?