> What you don't understand is that no process is going to die unless either
> someone is running away (in which case they'll get the bullet) or your
> system is horribly misconfigured (in which case you deserve your fate).
*Why* the machine is out of memory is not the issue. The issue is
what happens when you run out (whether due to stupidity in configuration
or otherwise).
All of the arguments I've seen so far assume that one process is
running off and grabbing all the available memory. That may be
the most likely scenario, but it's most certainly not the *only*
scenario. What if you have a whole bunch of "middle sized" processes
running, all using memory efficiently, but in total using 95% of
the available VM. A malloc(5*1024*1024) might work, but I need
10 MB instead of 5MB. And my memory footprint is just a little
bit bigger than the other guys. Instead of returning NULL to
the malloc() request, *zap* I'm dead. How can you possibly
call that sensible behaviour?
Yes, the machine is under-resourced. I can't help that -- it's not my
machine. The machine belongs to a customer who happens to run my IMAP
software, who also happens to have ignored our sizing guidelines. In
this situation I have no choice but to deal with the low memory
condition, and our code does that, if it's given the chance! At
least give me the opportunity to deal with the situation gracefully.
What if we decided to defer errors from bind just because there
weren't any mbufs available, and later killed the process when it
tried to do network I/O? People would howl bloody murder! (<== this is
rhetorical, folks)
The semantics of malloc() have been defined since almost the dawn of
time. From the current manpage:
RETURN VALUES
The malloc() and calloc() functions return a pointer to the allocated
memory if successful; otherwise a NULL pointer is returned.
Nowhere does it say that allocated memory might not exist. Nowhere
does it say that I have to touch all the allocated pages to make
sure they are really there. Nowhere does it say process death at
some non-deterministic time in the future might be a side effect
of calling malloc().
Applications are written assuming that malloc() behaves in the
documented manner. It is *not* acceptable to tell applications writers
that they have to provide their own management routines on top of malloc()
(SEGV catchers and the like) if they want the long standing semantics
of malloc() to be preserved. If the current malloc() cannot behave in
the documented and expected manner it needs to be renamed, because
malloc() it most certainly isn't.
--lyndon
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
