Proposed platform assumption changes

[Roland C. Dowdeswell]

On Fri, Jan 27, 2012 at 06:55:02PM -0500, ghudson at mit.edu wrote:
>

> * I also considered proposing an aborting malloc wrapper.  Platforms
>   generally respond to out-of-memory conditions by killing processes,
>   not returning null from malloc(), and checking for malloc failures
>   adds an extraordinary amount of failure handling logic to our code,
>   which again is difficult to test.  However, Kerberos code is
>   sometimes used in kernels or in embedded environments, and I'm
>   reluctant to make a change which might prevent it from being used
>   there.

I don't think that it is appropriate for a library to have unexpected
side-effects such as terminating the program.  xmalloc() and the like
are perfectly reasonable for programs but should not be used in libs.

It is also not true that malloc(3) cannot legitimately return NULL.
A simple example would be using a 32 bit machine (or a 32 bit
application running on a 64 bit machine) which has more than 4GB
of RAM+swap.  In this case, when a single process runs out of
address space malloc will return NULL but the machine will not need
to kill processes and will still be in a position to address all
of the currently existing memory.  Recovering gracefully and
returning an error in this case would be the behaviour that
application developers using the Kerberos libraries would intuitively
expect.

Another example would be a process which has a data limit set via
setrlimit(2).  Again, in this case, the process would be limited
to a reasonable amount of memory and the OS would not necessarily
be placed into the position where more memory had been allocated
than it had swap to back.

There are also OSes which limit total allocated memory (such as
Solaris?) and they'll obviously be able to return NULL from malloc(3)
before they have to start running around killing processes left
and right (generally starting with the most important process first
but I am still not sure quite how they managed to write a heuristic
that almost always knows which process I care most about.)

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/