From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <53d606a453b7463f930e6f906d9168bd@quanstro.net>
Date: Fri,  9 Jun 2006 19:23:11 -0500
From: quanstro@quanstro.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] quantity vs. quality
In-Reply-To: <20060610022738.GA22180@ionkov.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 66c78aae-ead1-11e9-9d60-3106f5b1d025

On Fri Jun  9 19:18:09 CDT 2006, lucho@gmx.net wrote:
> On Fri, Jun 09, 2006 at 06:51:00PM -0500, quanstro@quanstro.net said:
> > On Fri Jun  9 18:48:44 CDT 2006, lucho@gmx.net wrote:
> > > > 
> > > > what is the senerio you're thinking of where malloc could fail
> > > > and you can recover?
> > > 
> > > 
> > > Let's say you have a fossil like file server and you cannot malloc memory to
> > > process new requests. Do you want to flush the data buffers back to the disk
> > > before you die, you you want to die in some library without any flushing.
> > 
> > have you had a problem with fossil failing in this way?
> 
> IIRC fossil is not using libraries that call sysfatal. I said fossil like
> file server, not fossil. Let's say that I want to write a fossil-like file
> server. I cannot use lib9p, because it will call sysfatal and not give me
> chance to flush the buffers to the disk.
> 

sure you can.  sysfatal calls _sysfatal to do the deed.  redefine that to call your
fancy cleanup routine and you're golden.

but i think you're letting better be the enemy of good.  start off just letting
sysfatal run its course.  if you find real examples of recoverable failure, then
handle and test each one.

when i've taken this approach, i have never needed to recover from the 
error, but i have found some corefiles with interesting requests.  like malloc(-1).
that is another overlooked benefit of not recovering from every error at
the outset.

- erik