[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: malloc() patches round 3

From: Igor Khavkine
Subject: Re: malloc() patches round 3
Date: Thu, 23 Aug 2001 10:10:24 -0400
User-agent: Mutt/1.3.20i

On Thu, Aug 23, 2001 at 11:38:24AM +0200, Niels M?ller wrote:
> tb@becket.net (Thomas Bushnell, BSG) writes:

> Besides system-global exhastion of virtual memory, there's at least
> one more condition under which malloc() will fail: If there's some
> per-process or per-user memory use limit that is exceeded (does the
> Hurd implement limits yet)?
> I believe that some limitations are needed to make the system really
> robust. Say that some of the virtual memory is reserved for certain
> essential processes. Under low-memory conditions, most processes would
> get into trouble, but the special processes can still operate. They
> could ask processes nicely to release resources, stop and restart
> services, reboot the system in an orderly way, or do other strange
> things (like the IRIX way of just shooting random processes).
> What is the right thing to do also depends on the circumstances. For
> an unattended server, rebooting and logging the condition may be the
> best way to deal with the problem. For a machine that is used
> interactively, there may be better ways to deal with it. But to make
> possible any alternative to rebooting, libraries and servers mustn't
> crash randomly.

I think this pretty much sums up the point I was trying to make. I simply
believe two things (1) The system should be robust enough to give the
user enough freedom to choose an alternative course of action under
extreme conditions like resource exhaustion. And (2) The Operating System
should not cater to the bugs of applications running on top of it.

I've declared my intent to make Hurd as robust as possible in this sense.
I hope other will share my intent. But now we should let the code
speak for itself.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]