Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!amdahl!ems!pwcs!stag!daemon
From: to_stdnet@stag.UUCP
Newsgroups: comp.sys.atari.st
Subject: The BREAK program in comp.sources.atari.st
Message-ID: <574@stag.UUCP>
Date: 29 Aug 88 19:15:03 GMT
Sender: daemon@stag.UUCP
Lines: 35

From: dal@syntel.UUCP (Dale Schumacher)

[apratt@atari.UUCP (Allan Pratt) writes...]

[...2 problem descriptions...]
>
> Something that fixes both of these problems is to check the stacked SR
> from the interrupt.  If the processor was in User mode, you know (A)
> it isn't the desktop, and (B) you aren't a second-level interrupt,
> therefore (C) it's safe to call Pterm when you return.

This won't do you a whole lot of good if you're stuck in an OS call,
like waiting for a keyboard character, or doing disk i/o.  The window
where the program (user mode) has control could be VERY small, maybe
too small to hit between disk accesses.

> If it's NOT safe, the ctl-delete should be removed from the queue.
> That way, it's like it never happened.  This means it might take
> several Ctl-Deletes to stop a process, but the ones that don't
> stop it also won't do any harm.

Then I hit Ctl-Delete several times, maybe letting the key repeat in
order to hit the tiny "breakable" portion of the code, and the program
DOES finally stop, but now I have several "break" keys in the buffer,
and the SHELL I'm running will now break.  Maybe the program should be
rigged to clear the keyboard input buffer on program termination, or
better yet, ignore breaks for some fraction of a second after the program
terminates (easy to do by checking 200Hz clock values).

--
      Dale Schumacher                         399 Beacon Ave.
      (alias: Dalnefre')                      St. Paul, MN  55104
      ...pwcs!stag!syntel!dal                 United States of America
  "Man who says, 'It cannot be done', should not interrupt man who is
   doing it." -Ancient Chinese Proverb