On Fri Jun 9 19:18:09 CDT 2006, [EMAIL PROTECTED] wrote: > On Fri, Jun 09, 2006 at 06:51:00PM -0500, [EMAIL PROTECTED] said: > > On Fri Jun 9 18:48:44 CDT 2006, [EMAIL PROTECTED] 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
