Re: malloc() patches round 3

[Niels Möller]

tb@becket.net (Thomas Bushnell, BSG) writes:

> I have no objection to being more diligent about checking malloc
> returns, but I have *NEVER* seen a Unixoid system perform anything
> like sensibly in the event of virtual memory exhaustion.  The Mach
> kernel itself just crashes directly.  And that's *better* than
> diligently returning errors and trying to poke along, because it
> actually *fixes* the problem: the system comes up again, and works.
> Every system I've seen, when memory exhaustion happens, simply never
> functions right again until rebooted.

Besides system-global exhastion of virtual memory, there's at least
one more condition under which malloc() will fail: If there's some
per-process or per-user memory use limit that is exceeded (does the
Hurd implement limits yet)?

I believe that some limitations are needed to make the system really
robust. Say that some of the virtual memory is reserved for certain
essential processes. Under low-memory conditions, most processes would
get into trouble, but the special processes can still operate. They
could ask processes nicely to release resources, stop and restart
services, reboot the system in an orderly way, or do other strange
things (like the IRIX way of just shooting random processes).

What is the right thing to do also depends on the circumstances. For
an unattended server, rebooting and logging the condition may be the
best way to deal with the problem. For a machine that is used
interactively, there may be better ways to deal with it. But to make
possible any alternative to rebooting, libraries and servers mustn't
crash randomly.

For GNU programs, using xmalloc is the recommended way to deal with
out-of-memory conditions in most cases. But there are exceptions (like
emacs), that make an effort to be able to fail gracefully when memory
gets low. That won't work if proc or the the filesystem simply crashes
before emacs has done it's thing.

Sorry for the length of this message, all of you probably know all
this already.

/Niels