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
DBarker@system-m.phx.bull.com ( Deryk Barker) (09/05/90)
In V10#37 Doug Moen <doug@nixtdc.uucp> 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. Ah, what you want is the Multics operating system. The system which inspired Unix in the first place and which most Unix people never mention. The facility you desire exists in Multics, with a further feature: the process is not killed if no handler is found, but is suspended and another level of the command processor is pushed onto the stack. If you can somehow fix the problem which caused the stack overflow (or any other exception) then you can restart the suspended procedure at the faulting instruction. This even works for missing routines when you are using the dyamic linking facility (and you thought OS/2 invented dynamic links!). You can create the missing routine and restart the calling program; makes for a most impressive demo. Unfortunately, Honeywell, who inherited Multics from GE in 1971, capped the product in 1984 and it is no longer sold. There are still some systems in existence (I'm writing this on one now) and I shall miss it very much when it finally goes away. The finest OS every written - bar none. And "David M. Alexander" <david@neon.stanford.edu> replies: > 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. Nice that IBM is finally catching up - some 25 years after the original Multics design work.... Deryk Barker, Jupiter Software, Victoria BC. "Send Lawyers, Guns and Money, Dad, get me out of this!"
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
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/14/90)
in article <GRP.90Sep12130853@magpie.unify.uucp>, grp@unify.uucp (Greg Pasquariello) says: > In article <13061@letni.UUCP> doug@letni.UUCP (Doug Davis) writes: >> some os's may have special handling for external things, like signals for >> instance, when returning to a state via a longjmp(). > Actually, I think the original question/response was regarding not the generic > setjmp and longjmp, but a setjmp/longjmp that does exception handling, in a > manner similar to AIXv3. Then add HP-UX 7.0 to the list, which has variations on setjmp(3C) that allow saving or not saving the signal mask. Used in conjunction with sigaction/sigprocmask(2) (Posix), or sigvector/sigsetmask/sigblock(2) (HP). -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu