Re: [9fans] quantity vs. quality

[quanstro@quanstro.net]

On Sat Jun 10 23:41:04 CDT 2006, rsc@swtch.com wrote:
> When I ported dns I was very impressed that
> it correctly handled rfork failing (because p9p
> doesn't do shared-memory rfork).  

you've got to admit this was a fortuitous accident.  and
dns doesn't need rfork do do one request -- it needs rfork
to handle a second request concurrently.  dns didn't really
work that well with the broken rfork.

> You can argue
> about cutting corners all you want, but it's a 
> slippery slope.

i don't think it's about cutting corners. 

what do you do when
- a library can't allocate 10 bytes? or 20?
- malloc detects a double-free or somebody has stepped
on it's datastructures.

isn't this much different than
- a library can allocate 64k or 1m

trying to recover from some errors is worse than dying.
dying gives you the oppertunity to fix the problem.
not dying can cover real bugs.

> 
> You end up with more robust software when you
> think about what to do in the error cases instead
> of just assuming they won't happen.

if you're going to put that code in, it needs to be tested.
in commercial software, my worst experiences have been
with recovery code that didn't work.

- erik