Hi Chris,
On Sun, 5 Dec 1999, Christopher T. Lansdown wrote:
> Actually, I don't like programs that abort gracefully at the drop of
> a hat. While not necessary, it would be nicer to have some sort of wait
> state, where if the program runs out of memory, something is written like
> that to the screen (with all the memory for this allocated out), and then it
> waits there so that the user can either free up memory or kill the program
> himself.
This assumes that the operating system can function normally (i.e. the
kernel runs and at least one unoccupied shell works) even though we're out
of memory. I agree that we generally should assume that it works that way.
> While aborting gracefully is more aesthetically pleasant, when you
> get down to it, what does it matter if your program just dies when your
> system runs out of memory and your program segfaulting?
Dying is more stylish and doesn't litter the harddisk with core dumps.
[Robustness in low-memory situations]
> Which is better? I mean, I realize that a simple game isn't really that
> important, but how hard would it be to do our own sort of sci_malloc() which
> does all of the appropriate checking, etc. and does the whole waiting thing
> instead of dying on error conditions? We'd still be at the mercy of the
> libraries that we're using, but it would be better than necessarily dying on
> not-necessarily fatal conditions. I mean really. Who of us hasn't run
> some program which had a bug in it which caused it to eat all memory, then
> we kill it? Does it really make the most sense for everything else to die
> because of one errant program?
You have a point there.
However, in low memory situations, games are generally the first things
the local system administrator will kill, and the reason for this is
obvious.
For an /application/ program, staying alive is important- you might loose
important data if it doesn't. Games aren't important; if they commit
suicide in low-memory situations, they might actually save the lives of
other, more important programs.
On the other hand, working around other progams' bugs isn't exactly what
we should be doing; we've got our own bugs to tend to.
Anyway, this isn't really worth arguing about- from an engineering point
view, you are right that a program should behave as robustly as possible.
Writing sci_malloc(), sci_realloc() and sci_calloc() shouldn't be too much
work either. If someone needs a different low memory policy, those
functions can be #defined to wrap around the glib functions instead with a
minimum amount of work.
So let's do it that way.
llap,
Christoph
