Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!gatech!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: File Truncation Philosophy
Message-ID: <1993Apr22.013557.12767@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C5LJ2u.1Ep@sugar.neosoft.com> <1993Apr18.012731.23976@fcom.cc.utah.edu> <C5t8Ft.EE8@sugar.neosoft.com>
Date: Thu, 22 Apr 93 01:35:57 GMT
Lines: 128
In article <C5t8Ft.EE8@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes:
>In article <1993Apr18.012731.23976@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>> No more than a reasonable application will care if signal sets aren't
>> contiguous in Posix signals so that a for loop doing sigest()'s can't
>> ever work.
>
>I wouldn't ever write a loop that trapped signals I wasn't prepared to handle.
>That's horrible coding practice.
Bah, Humbug!
The idea is not to trap signals, but to untrp signals in a child process
whose trap values (like SIG_IGNORE) where inherited from the parent; the
problem is *restoring* the default action for each signal:
] After a fork(2V), or vfork(2) the child inherits all sig-
] nals, the signal mask, the signal stack, and the
] restart/interrupt and reset-signal-handler flags.
The problem is that this is no longer simple under Posix; however, there
*is* a correct way to do it that is guaranteed to be portable, where the
normally expected "for" loop is not.
>> 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. Not only does this give us a well defined system interface
that behaves in a predictable way, it makes systems with bogus error returns
obvious (by way of "abend or failsoft"). All software written to the
interface will run the same on all systems with the interface. That is the
point of Posix.
>Limiting errno values because some broken program might
>mess up when it gets ETXTBSY or (for that matter) EMACS (Editor too big :>)
>is a bad idea. No matter *what* POSIX says, any program that assumes the
>set of possible error returns won't increase is broken.
It shouldn't assume that the error set will not increase; 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").
Besides, a program should not have to know the failure recovery procedure
for something that can be auto-recovered by the system software.
>> What do you do in a program that returns an unexpected failure mode if
>> the only code you have written deals with expected failure modes?
>
>Broken code is always a problem.
If you limit the scope of the environment, there will be less broken code
(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). Personally, I'm torn between condemning it
as a crutch and acclaiming it for freeing me from "fixing" bad code.
>> I can't have exec() or open return ETXTBSY when it can never happen
>> elsewhere
>
>What do you mean "it can never happen elsewhere"? It happens on existing
>systems right now!
Only very, very old ones, and ones with an "unfixed" MACH VM system.
>> Better to "just work" in the kernel by copying to swap and retrying than
>> to return any error in a case that would normally result in ETXTBSY were
>> the kernel not trapping and handling the swap store workaround for you.
>
>I disagree. Adding complexity to the kernel (and chewing up swap space) to
>cater to broken code is bogus. It's doubly bogus when you can legitimately
>treat it as any other mandatory lock.
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. There isn't any lock
subsystem burrently in the kernel, and I'm too close to one at work to
provide one... I can, however, do the VM fix without any conflict of interest.
>> In my opinion *only* reasonable applications will have problems! It's
>> only the *reasonable* applications that trap and handle errors in the first
>> place;
>
>I'm sorry, but there are two primary rules violated here:
>
> 1. Don't trap errors you don't know how to handle.
Not doing this; just trapping the ones I know about and suprising the hell
out of the user when an otherwise recoverable, but unfortunately "unique"
to the target system, error occurs, instead of just running.
There is a rule being violated here, but it is the "rule of least
astonishment", not the "rule of error trapping". Simply stated:
Rule of least astonishment:
Software should always act in such a way as to not suprise the
user with the results of his actions.
> 2. Don't assume that new types of errors won't show up.
Not doing this, either; just trying to do preemptive damage control. This
is in line with the corollary to the "rule of error trapping":
Rule of error trapping:
Don't trap error conditions you can't recover from.
Corollary:
Don't change an existing system so that it generates errors
which are not trapped in existing software. You may make the
existing software violate the "rule of error trapping".
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------