home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / atari / st / tech / 4474 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.2 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!usc!elroy.jpl.nasa.gov!ucla-cs!ucla-se!pantheon!willing
  2. From: willing@pantheon.icsl.ucla.edu (Scott Willingham)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: Re: Trapping ^C
  5. Message-ID: <7876@lee.SEAS.UCLA.EDU>
  6. Date: 19 Aug 92 17:21:55 GMT
  7. References: <1992Aug14.103938.1@uwovax.uwo.ca> <1992Aug15.220008.22145@mnemosyne.cs.du.edu> <1992Aug17.172819.7279@pbhya.PacBell.COM>
  8. Sender: news@SEAS.UCLA.EDU
  9. Organization: University of California at Los Angeles, EE Dept.
  10. Lines: 46
  11.  
  12. In article <1992Aug17.172819.7279@pbhya.PacBell.COM> dbsuthe@PacBell.COM
  13.   (Daniel B. Suthers) writes:
  14. >In article <1992Aug15.220008.22145@mnemosyne.cs.du.edu> ilepore@nyx.cs.du.edu
  15.   (Ian Lepore) writes:
  16. >> 
  17. >> Yeah ::sigh:: unfortunately what I'm doing is trying to build a signal()
  18. >>system for dlibs, for folks not running under MiNT.
  19. >> 
  20. >> 
  21. >> Aw sh*t you're kidding!  I hadn't checked it, I just assumed GEMDOS would
  22. >>be bright enough to manage the pterm vector on a per-process basis.
  23. >> 
  24. >> Actually, I had about given up on implementing SIGINT at all, but I was 
  25. >>gonna implement the ANSI-defined SIGTERM and tie it to the termination 
  26. >>vector.  I was also going to use the termination vector to clean up hooks
  27. >>in other vectors (for handling SIGSEGV and stuff).  It looks like this is
  28. >
  29. >This is just an idea as I have no docs to check...
  30. >
  31. >After intercepting the call, could you not check the keyboard to see what the
  32. >last character was?  It should still be there (somewhere) to tell you what
  33. >had happened.
  34.  
  35. Sorry, but I don't think that will work.  I was hacking around at one time
  36. on the MiNT kernel and attempting something similar.  I hooked into the
  37. keyboard vector, trying to delete ^C from the keyboard buffer before
  38. Cconws(), etc. could detect it.  Although I never disassembled the BIOS to
  39. verify this, it appears that the ^C often never gets into the keyboard
  40. buffer.  I suspect that the keyboard interrupt handler takes action on
  41. the ^C as soon as it comes in (this must be flagged to occur only when
  42. higher level I/O routines are active...).  Perhaps I screwed up in my
  43. code somewhere, but I could never find a ^C anywhere in the buffer.
  44.  
  45. Scott Willingham // willing@icsl.ucla.edu
  46. .
  47. .
  48. .
  49. .
  50. .
  51. .
  52. .
  53. .
  54. .
  55. .
  56. .
  57.  
  58.