Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!oliveb!amiga!neil
From: neil@amiga.UUCP (Neil Katin)
Newsgroups: comp.sys.amiga
Subject: Re: Re: Recognizing the break character
Message-ID: <2674@amiga.UUCP>
Date: 27 Jul 88 17:24:14 GMT
References: <3498@louie.udel.EDU>
Reply-To: neil@spam.UUCP (Neil Katin)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 63


In <19460@cornell.UUCP> blandy@marduk.cs.cornell.edu (Jim Blandy) writes: 
>This is where I get lost.  What am I allowed to do in this exception? 
>Can I call exit()?  I suppose one should restore the original contents
>of the tc_ExceptCode field for the CLI, since we're sharing a process,
>right?   I've tried some variation on this before, and it's always
>crashed. ...helphelpplehpleh...


In article <3498@louie.udel.EDU> iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) writes:
>All this is related to the question I had about using an Exception Handler
>to simulate a Unix signal catch.  I'd still like to see a solution that
>does not involve polling (although I can see that polling is what you want
>in some cases).  The problem is that the semantics are different.  A caught
>Unix signal causes a longjmp, whereas an Amiga Exception is a rather
>special form of subroutine call, and must return to the OS.


This is an issue that comes up every few months, and while it's
been answered before, it's important enough to repeat.

First of all, the EXEC exception handler is fully general.  You
can longjmp out of it to previous call frames, just as in UNIX.
Indeed, the whole idea of Amiga execeptions was to allow unix-like
signal processing.

We implemented it (back in V21, if memory serves).  We tested it.
We loved it.  We used it.  We crashed with it.

The problem is a fundamental one in the amiga's design.  Short of
redesigning the task model, EXCEPTIONS ARE LIMITED IN USE TO ONLY
VERY CONSTRAINED CONDITIONS, which almost never exist in normal
use.

The heart of the problem is that libraries and devices (the
things that get most of the grunt work done) run on your stack,
in your context.  They don't know about your exceptions, yet
they have changed their internal state, and "assume" they will
retain control until they can change it back.

When you take an exception and longjmp() back on your stack
these libraries lose control and typically crash and burn.
(remember that in UNIX all grunt work is done in the kernel,
which is not reentrant or interruptable by other tasks or signals
except by special arrangement).

We talked about changing libraries to turn off exceptions in
their critical regions, but the "max throughput" people didn't
want the extra overhead.

So when is it save to use exceptions?  ONLY WHEN YOU ARE NOT CALLING
ANY LIBRARIES OR DEVICES.  If you are in a cpu intensive section
of code and don't want to poll, you can turn exceptions on.
However, everyone I know has found polling to be easier than
saving and restoring exceptions at the proper time.

An obvious answer (never implement, to my knowledge) is to
make a special set of link libraries which save and restore
the exception mask, thereby relieving the programmer of the
burden of tracking this stuff.  I'ld be interested in
hearing if it works.  Or maybe I'll add it to my GNU C port...

	Neil Katin
	(the person guilty of adding exceptions to exec...)