doug@nixtdc.uucp (Doug Moen) (09/02/90)
>eliot@dg-rtp.dg.com writes: >> But consider the reading case. > [ what happens upon failure? ] brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >As Peter pointed out, this case is fatal. How many disk errors have you >had over the last year? How many did the programs involved recover from? >Yeah, thought so. Sorry, but this is unacceptable. If I am using a text editor, and try to write out a file, and the write fails due to an I/O error, then any decent editor will simply report the error, and return to command mode, which allows me to attempt to write the file somewhere else, and save my work. The operating system should not under any circumstances kill my editor because of a file i/o error. In fact, I will go further, and claim that the operating system should not kill a program out of hand, no matter what sort of error occurs. Error handling in Unix is already a joke; kernel modifications that make it impossible to write robust programs are not going to help the situation. Here's the obligatory new idea: I don't like the fact that Unix kills a process if it blows the stack due to an infinite recursive loop. The problem could be fixed with the introduction of an exception handling mechanism that the kernel knows about. If the stack overflows, then the kernel raises an exception within the offending process. The exception unwinds the stack (thereby recovering stack space) until a stack frame containing an exception handler is found. If no exception handler is active, then (and only then) is the process killed. -- Doug Moen {mnetor,alias,geac,torsqnt,lsuc}!nixtdc!doug 77 Carlton #1504, Toronto, Ontario, Canada M5B 2J7
david@Neon.Stanford.EDU (David M. Alexander) (09/04/90)
In article <1990Sep2.050854.12008@nixtdc.uucp> doug@nixtdc.UUCP (Doug Moen) writes: >Here's the obligatory new idea: >I don't like the fact that Unix kills a process if it blows the stack >due to an infinite recursive loop. The problem could be fixed with >the introduction of an exception handling mechanism that the kernel >knows about. If the stack overflows, then the kernel raises an exception >within the offending process. The exception unwinds the stack (thereby >recovering stack space) until a stack frame containing an exception >handler is found. If no exception handler is active, then (and only then) >is the process killed. >-- >Doug Moen >{mnetor,alias,geac,torsqnt,lsuc}!nixtdc!doug >77 Carlton #1504, Toronto, Ontario, Canada M5B 2J7 You must have been reading about AIXv3 setjmp() and longjmp() recently. You can use these calls to do exactly that. AIXv3 is turning out to be a really nice OS. Dave Alexander
tim@Xsys..uucp (Tim Dawson) (09/05/90)
david@Neon.Stanford.EDU (David M. Alexander) writes: >You must have been reading about AIXv3 setjmp() and longjmp() recently. >You can use these calls to do exactly that. >AIXv3 is turning out to be a really nice OS. I hate to pop this bubble, but setjmp() and longjmp() are NOT from AIX - they are a part of the SysVR3 release from AT&T and are utilized within Unix, among other places. Source of my information: AT&T System 5 Release 3 internals training. I have not checked too many OS ports, but this (based on the above) exists in AIX, and also exists in Motorola SysV68 and SysV88, and I suspect in most all ports of System V Release 3! Let's not give IBM credit for something that they definitely did NOT come up with! -- ================================================================================ Tim Dawson (...!texsun!Athena!tim) Motorola Computer Systems, Dallas, TX. "God gave me a brain and I give Him the glory by using it!"
merriman@ccavax.camb.com (09/06/90)
In article <1990Sep2.050854.12008@nixtdc.uucp>, doug@nixtdc.uucp (Doug Moen) writes: [stuff deleted] > Here's the obligatory new idea: > I don't like the fact that Unix kills a process if it blows the stack > due to an infinite recursive loop. The problem could be fixed with > the introduction of an exception handling mechanism that the kernel > knows about. If the stack overflows, then the kernel raises an exception > within the offending process. The exception unwinds the stack (thereby > recovering stack space) until a stack frame containing an exception > handler is found. If no exception handler is active, then (and only then) > is the process killed. > -- Sounds a lot like VMS exception handlers
doug@letni.UUCP (Doug Davis) (09/11/90)
In article <tim.652548167@Xsys> tim@Xsys..uucp (Tim Dawson) writes: >david@Neon.Stanford.EDU (David M. Alexander) writes: >>You must have been reading about AIXv3 setjmp() and longjmp() recently. >I hate to pop this bubble, but setjmp() and longjmp() are NOT from AIX >they are a part of the SysVR3 release from AT&T and are utilized within Unix Uh, just to streighten the record a bit more, setjmp()/longjmp() in user programs have been around since at least V7. Basicly all they are is a save/recover of the register states of a process, kinda like push & pop or movem instructions, but from within a C program. Additionally some os's may have special handling for external things, like signals for instance, when returning to a state via a longjmp(). doug __ Doug Davis/4409 Sarazen/Mesquite Texas, 75150/214-270-9226 {texsun|lawnet|smu}!letni!doug doug@letni.lonestar.org "Be seeing you..."
lance@motcsd.csd.mot.com (lance.norskog) (09/11/90)
Setjmp() and longjmp() are the basis of UNIX process-switching, and they've
been in the kernel since Version 6 (1976?) and probably since the original
PDP-11 assembler implementation. This pair are:
void setjmp(jump buf)
void longjmp(jump buf)
The user-library pair have been around for probably as long:
int setjmp(jump buf)
void longmmp(jump buf, return val)
switch (setjmp(jumpbuf)) {
case 0: original
case 1: abort
default: panic, can't happen
}
abort:
longjmp(jumpbuf, 1);
Setjmp() in the user library returns 0 for the setup call, and the
longjmp-supplied value when it comes back from a longjmp().
The kernel pair lacks this functionality.
Of course, better languages let you save off multiple running stacks
and resume them...paul@unhtel.uucp (Paul S. Sawyer) (09/12/90)
In article <tim.652548167@Xsys> tim@Xsys..uucp (Tim Dawson) writes: >david@Neon.Stanford.EDU (David M. Alexander) writes: > >>You must have been reading about AIXv3 setjmp() and longjmp() recently. >>You can use these calls to do exactly that. >>AIXv3 is turning out to be a really nice OS. > >I hate to pop this bubble, but setjmp() and longjmp() are NOT from AIX - they >are a part of the SysVR3 release from AT&T and are utilized within Unix, among >other places. Source of my information: AT&T System 5 Release 3 internals >training. I have not checked too many OS ports, but this (based on the above) >exists in AIX, and also exists in Motorola SysV68 and SysV88, and I suspect in >most all ports of System V Release 3! Let's not give IBM credit for something >that they definitely did NOT come up with! >-- They were in System V Release 2.0 and 2.1, also; Prog. Ref. Manual, setjmp(3C). Wait - - Release [1.]5.3 had it too - - guess SysV "always" did! -- Paul S. Sawyer uunet!unh!unhtel!paul paul@unhtel.UUCP UNH Telecommunications attmail!psawyer p_sawyer@UNHH.BITNET Durham, NH 03824-3523 VOX: +1 603 862 3262 FAX: +1 603 862 2030