iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) (07/27/88)
[In "Re: Recognizing the break character?", Wayne Young said:] > > If you look around in some of the earlier Fish disks, you'll find a little > gem that Fred wrote himself. It's a cc command for Lattice, and it comes > with sources. There's some code in it which checks for ^C, and you can > easily extract the necessary stuff to make your own check_abort() routine. > -- > {uunet,utzoo,decvax,allegra}!utcsri!utflis!wayne > Cc is on Fish Disks #2, 29 and 43. I have #29, and what Fred is doing is calling the Aztec Chk_Abort() function. According to the manual, Chk_Abort(): "aborts the program if (1) ^C has been typed and (2) the global short Enable_Abort is non-zero (which it is by default). If either of these conditions isn't satisfied, Chk_Abort() simply returns." Fred is using an undocumented (or underdocumented) feature, namely WHAT it returns. Chk_Abort() returns the result of SetSignal(0L,0x1000L), which can be used as a Boolean to poll for ^C. 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. -- Bill Kinnersley Physics Department BITNET: iphwk@mtsunix1 Montana State University INTERNET: iphwk%mtsunix1.bitnet@cunyvm.cuny.edu Bozeman, MT 59717 CSNET: iphwk%mtsunix1.bitnet@relay.cs.net (406)994-3614 UUCP: ...psuvax1!mtsunix1.bitnet!iphwk "He learned to communicate with birds and discovered that their conversation was fantastically boring. It was all to do with wind speed, wingspan, power-to-weight ratios and a fair bit about berries."
me142-an@kepler.Berkeley.EDU (sp88 class acct) (07/27/88)
The ^C is very easy to detect. You must look in tc_sigrecvd to find
a sigbreakf_ctrl_c. The following code does this
move.l 4,a6 ; execbase
move.l thistask(a6),a0 ; my task structure
move.l tc_sigrecvd(a0),d0 ;signals we have received
andi.l #sigbeakf_ctrl_c,d0 ; the ^c flags
bne userdidhit^c ; a one bit in tc_sigrecvd means we were signaled
whatever you were doing.....
if you want to actually wait for a ^c, do
move.l 4,a6
move.l #sigbreakf_ctrl_c,d0
jsr _LVOWait(a6)
etc,etc,etc....
(note that my upper case/lower case in the symbols is frequently not what
Commodore/Amiga intended. Mixed case in symbols is disgusting!)neil@amiga.UUCP (Neil Katin) (07/28/88)
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...)
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (07/30/88)
In article <2674@amiga.UUCP> neil@spam.UUCP (Neil Katin) writes:
: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. [ ... ]
:
: Neil Katin
: (the person guilty of adding exceptions to exec...)
Don't feel guilty; exceptions are great. I've used them in the
aforementioned constrained conditions, and they work very nicely.
Matt Dillon made their use even more attractive when he created
'qint', which is a form of Forbid()/Permit() for exception signals only. As
long as the task manages its interrupts correctly, they can be just as
useful as the UNIX equivalent (albeit more trouble to use).
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
\_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctorba@m2-net.UUCP (Bill Allen) (08/05/88)
Is ^C accurately detected from CLI this way? I frequently get "** File abandoned" when using AmigaDOS's c:Search command. The system thinks ^C was hit when it has not been. Oddly, ARP's new and improved Search command has the same problem.
iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) (08/06/88)
[In "Re: Re: Recognizing the break character", Bill Allen said:] > > Is ^C accurately detected from CLI this way? I frequently get > "** File abandoned" when using AmigaDOS's c:Search command. The > system thinks ^C was hit when it has not been. Oddly, ARP's new > and improved Search command has the same problem. > This demonstrates the importance of resetting the signals when you're done. SEARCH doesn't recognize ^C at all, documentation to the contrary. It recognizes ^D, but fails to reset it, so that the next SEARCH immediately abandons the first file.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/07/88)
>Is ^C accurately detected from CLI this way? I frequently get >"** File abandoned" when using AmigaDOS's c:Search command. The >system thinks ^C was hit when it has not been. Oddly, ARP's new >and improved Search command has the same problem. This is a bug in the CLI. CLI forgets to CLEAR the SIGBREAKF_CTL_C signal, and possibly the others (D, E, and F). So if the application program doesn't clear the signal on startup, you can get false breaks. I don't have the problem.... I use a shell. I assume it will be fixed in 1.3/1.4 ? -Matt
andy@cbmvax.UUCP (Andy Finkel) (08/09/88)
In article <2109@m2-net.UUCP> ba@m-net.UUCP (Bill Allen) writes: >Is ^C accurately detected from CLI this way? I frequently get >"** File abandoned" when using AmigaDOS's c:Search command. The >system thinks ^C was hit when it has not been. Oddly, ARP's new >and improved Search command has the same problem. There was a bug in Search. It wasn't looking at the right signal bit. (and wasn't looking in the right place) Its fixed for 1.3. So it works as documented. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If we can't fix it, it ain't broke." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.