On Sat Jun 10 23:41:04 CDT 2006, [EMAIL PROTECTED] 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
