Khimenko Victor wrote:
>
> In <880.101T2300T1215172rask@kampsax.k-net.dk> Rask Ingemann Lambertsen (rask@kampsax.k-net.dk) wrote:
> > Den 06-Mar-00 23:53:26 skrev Stephen C. Tweedie f?lgende om "Re: Linux 2.2.15pre12":
>
> > ['hard' memory allocation policy]
>
> >> Your user space app uses all the memory it can and then gets ENOMEM on
> >> the next malloc. Fine.
>
> >> Then named does a malloc. It gets ENOMEM and dies,
>
> > That would be a very silly reaction to ENOMEM for a program like named.
> > The same goes for inetd, sendmail and init and other such programs.
>
> Feel free to cook up patches for few hundreds affected programs. Once you'll
> finish we can think about you approach again. Ok?
>
> P.S. You can all it any way you want but it's sad truth: syslogd, klogd, named
> and LOTS and LOTS of other daemons will die if malloc will return ENOMEM.
> Welcome to real world from your ivory tower :-)
I'll say the obvious...
It either gets ENOMEM or it gets SIGKILL. If an essential daemon dies
when it gets ENOMEM then it's broken. You can in fact get ENOMEM
returned for some syscalls under the current scheme if you're very
lucky. Either way a broken program will die, but at least you can patch
it to handle ENOMEM.
There really are a lot of cases where this behavior would be beneficial,
and there are too many people brushing aside the whole idea, often with
strong words. A good example is any embedded system (you can see where
I'm coming from here) where every running process is tailored. Not that
I'm implying this should be made the default scheme.
-- John Ripley, empeg Ltd. http://www.empeg.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:24 EST