Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!tulane!wupost!howland.reston.ans.net!zaphod.mps.ohio-state.edu!menudo.uh.edu!uuneo!sugar!peter From: peter@NeoSoft.com (Peter da Silva) Subject: Re: File Truncation Philosophy Organization: NeoSoft Communications Services -- (713) 684-5900 Date: Fri, 23 Apr 1993 23:40:32 GMT Message-ID: <C5yn3L.1qA@sugar.neosoft.com> References: <1993Apr18.012731.23976@fcom.cc.utah.edu> <C5t8Ft.EE8@sugar.neosoft.com> <1993Apr22.013557.12767@fcom.cc.utah.edu> Lines: 100 In article <1993Apr22.013557.12767@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > >> Seriously, the return codes from "system" and "exec" need to be meaningful > >> in all cases; that means documented, so that failures can be trapped. > >Again, you need to trap failures you can handle, and abend or failsoft on > >failures you can't. > Exactly my point -- limit the types of failures that can occur so that they > can be trapped. That means if a new failure mode shows up, that requires a different correction mechanism, you can never check for it so you're forever trying to figure out a way to kludge things so it doesn't show through to the application. That is, failures occur. Handle them. Chewing up extra swap space (and increasing the chance of some unrelated process dying) is less desirable than returning a failure condition (ETXTBSY). This is one of the main things I see wrong with NFS, for example. If a server goes away for a significant amount of time, you should get an ENETCLOSE (NFS connection closed) so you can continue (say, give control back to the user) instead of hanging forever (or until the user gives up and reboots). A programmer should expect that errno will occasionally return values that didn't exist when he wrote the program. > It shouldn't assume that the error set will not increase; But that's just what you said above... that a program should never have to deal with new errors. > however, ETXTBSY > is an antiquated error whose use should be deprecated (and eliminated where > possible -- and it's definitely possible on 386BSD if it's done "right"). The only place it should be eliminated is in unlink(). > Besides, a program should not have to know the failure recovery procedure > for something that can be auto-recovered by the system software. What's the correct recovery mode? > >Broken code is always a problem. > If you limit the scope of the environment, there will be less broken code No, there will be just as much broken code... it will just hide out until a new failure mode you can't sweep under the rug develops. > (I know; this begs the question regarding portability of code, like you > can really be said to have "portable" software if it runs on a Compaq and > and IBM machine under DOS). Try porting a few net programs to Xenix-286. That'll give you some appreciation for the amount of junk out there. 386BSD/NetBSD is full of it, by the way. > >What do you mean "it can never happen elsewhere"? It happens on existing > >systems right now! > Only very, very old ones, System V release 3 isn't that old. > and ones with an "unfixed" MACH VM system. I've got 200 developers on one of those old systems. > If this i true, then it should actually assert a lock (so we can replace it > with a Mutex for an SMP implementation), and there should be a locking > system in place that is otherwise generally useful. That's a valid resolution. And a locking subsystem is definitely needed. In the meantime it can be made to *act* like a lock, so that code won't break when it gets put in. > Rule of least astonishment: > Software should always act in such a way as to not suprise the > user with the results of his actions. So you copy a new version of Ghostscript in while Ghostscript is running and suddenly you're out of VM and the system dies. Oops. Having a program print "Text File Busy" is a LOT less astonishing. > Don't change an existing system so that it generates errors > which are not trapped in existing software. Any existing software that can't deal with ETXTBSY is broken on a lot of existing systems. But, while we're playing with rules: KISS -- Peter da Silva. <peter@sugar.neosoft.com>. `-_-' Har du kramat din varg idag? 'U` My Apple-II has more RAM than my Mac!