From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <a6d09dc0193d1dd8ddf1931949479f5b@quanstro.net>
Date: Sat, 10 Jun 2006 19:44:29 -0500
From: quanstro@quanstro.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] quantity vs. quality
In-Reply-To: <448B5229.8050008@lanl.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 67b3d7a6-ead1-11e9-9d60-3106f5b1d025

On Sat Jun 10 18:16:52 CDT 2006, rminnich@lanl.gov wrote:
> A fork fails.
> 
> Which would you rather have the kernel do: panic? Lock up (as in the old 
> days)? Or handle it gracefully.

i was talking about applications.  and usually applications can deal with fork
failure.  maybe counterproductively.

> 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).

i don't know.  it's hard to say without looking at it.  it's hard for me to just say
"ya, it should do that" because linux is an example of how that can go.  
you should be able to boot from cd, though?  

would this work:  lets say i have everything i need to boot on a fossilfs main
and stuff i can boot without (and could much more easily fill) on fossilfs 
otherstuff.  will fossil continue with the main fs and ignore the full one?

> 
> 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. 

agreed.

> 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.

mostly agreed.  i'd go for it's /often/ better to quit.  and the downside
of the library not quitting is now you get to add a bunch of error
code to /sys/src/cmd.  

> 
> 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?

would it really matter?  if everybody tried their hardest to continue
in the face of errors, you'd never be able to fork a process and fix anything.

damned if you do, damned if you don't.

- erik