From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <448B5229.8050008@lanl.gov>
Date: Sat, 10 Jun 2006 17:13:45 -0600
From: Ronald G Minnich <rminnich@lanl.gov>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] quantity vs. quality
References: <20060610015739.GA21966@ionkov.net>	<59f06232334eddd74b8f1c78efe5621b@quanstro.net>	<20060610001024.GB2291@submarine>	<20060610023116.GB22180@ionkov.net>
	<20060610004529.GD2291@submarine>
In-Reply-To: <20060610004529.GD2291@submarine>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 678da1da-ead1-11e9-9d60-3106f5b1d025

A fork fails.

Which would you rather have the kernel do: panic? Lock up (as in the old 
days)? Or handle it gracefully.

Your fossil fills up completely. Which would you rather have it do: blow 
up on boot, so you can no longer boot your system (current behavior); or 
manage disk space so that, even in the worst of all cases, you can still 
get booted enough to try to clean up (most unix file systems since 1980 
or so).

Nobody's arguing for "best enemy of good". All we're trying to say is, 
that there are times a library should not make the decision to 
sysfatal() on you. And, there are many real world examples of resource 
exhaustion where continuing to run is better than dying. It's not always 
better to run, and it may not be better to run in most cases, but 
sometimes it is really better not to have the library pre-emptively 
decide to exit; in fact, you want a reasonable return value.

I do believe that the shell can handle the case of some types of 
resource exhaustion:

	switch(forkid = fork()){
	case -1:
		Xerror("try again");
		break;


would you want rc to exit in this case?

ron