Andrew Lentvorski wrote: > Christopher Smith wrote: > >>> Something as simple as "out of memory" causes better than 99% of all >>> programs to die with horrible corruption. There is no reason for that >>> other than the fact that no one takes the time to code it. >> Here I have to disagree with. For a whole host of programs, running out >> of memory is an indication that something is seriously wrong. > Only *if you're the one causing the out of memory*. Well, the OOM killer issue is a whole other different thread, but needless to say it is a way harder problem to handle correctly than one might think. > Otherwise, this is a *bug*. Why don't systems request enough memory > up front to shut down gracefully? Because programming that is hard > and nobody cares. No, because often writing a ton of code to handle such conditions actually introduces more bugs than it could possibly get rid of. It is actually pretty graceful to just die and let the good kernel clean up the mess. I used to write all kinds of recovery code for every conceivable occurrence until I learned this principle. It turns out just plain old "dying" and then having the user, inittab, or a parent process clean up the mess is far less error prone. > If I soak up all the RAM, half my daemons will croak in various states > of corruption instead of shut down cleanly. Define "corruption"?
--Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
