From mboxrd@z Thu Jan  1 00:00:00 1970
Mime-Version: 1.0 (Apple Message framework v750)
In-Reply-To: <e09c0731e598b475b1868e0e3360de4e@quanstro.net>
References: <e09c0731e598b475b1868e0e3360de4e@quanstro.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D83D0E81-09A9-4974-9442-5C03859933B5@lanl.gov>
Content-Transfer-Encoding: 7bit
From: Latchesar Ionkov <lionkov@lanl.gov>
Subject: Re: [9fans] quantity vs. quality
Date: Fri,  9 Jun 2006 17:19:20 -0600
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Topicbox-Message-UUID: 659b0d54-ead1-11e9-9d60-3106f5b1d025

There are cases when you want to leave the output of the program in  
consistent state before you die (and you don't need extra memory to  
achieve that consistency). Or even if the program cannot continue its  
work, it would rather lurk around and wait for somebody to rescue it  
instead of just dying. And in cases like that you just cannot use  
libraries that call sysfatal.

Thanks,
	Lucho

On Jun 9, 2006, at 4:55 PM, quanstro@quanstro.net wrote:

> 've written many production systems this way.  i never once had a  
> malloc
> failure that was not a result of a catastrophic bug or h/w failure.
>
> except in the case where you know you might be requesting an  
> unreasonable
> amount of memory, i have always thought that it makes more sense to  
> limit
> the number of failure states by just quitting when malloc fails.  i  
> want my
> programs to be as deterministic as possible. i would much rather  
> have them
> die than get into some untested failure state. (does any project  
> that tries
> to recover from malloc failure actually test failure at each  
> recovery point?)
>
> the current fad is c++ exceptions.  the idea seems okay, but the  
> programs
> i know that make use of c++ this way (mozilla comes to mind) do not
> seem to be very stable or reliable.
>
> - erik
>
> On Fri Jun  9 17:53:03 CDT 2006, lionkov@lanl.gov wrote:
>> Another example is using emalloc in libraries. I agree that it is
>> much simpler to just give up when there is not enough memory (which
>> is also not very likely case), but is that how the code is supposed
>> to be written if you are not doing research?
>>
>> Thanks,
>> 	Lucho