home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / amiga / programm / 19151 < prev    next >
Encoding:
Text File  |  1993-01-25  |  2.9 KB  |  66 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!gatech!concert!samba!usenet
  3. From: Todd_Lewis@unc.edu (Todd M. Lewis)
  4. Subject: Re: Aborting Timer requests
  5. Message-ID: <1993Jan25.140359.4296@samba.oit.unc.edu>
  6. Sender: usenet@samba.oit.unc.edu
  7. Nntp-Posting-Host: guitar.oit.unc.edu
  8. Organization: UNC Office of Information Technology
  9. References: <nsgls*pb1@wolf359.UUCP>
  10. Date: Mon, 25 Jan 1993 14:03:59 GMT
  11. Lines: 53
  12.  
  13. In article <nsgls*pb1@wolf359.UUCP> eric@wolf359.UUCP (Eric Edwards) writes:
  14. >Can someone give me some insight on the proper way to abort a timer
  15. >request?
  16.  
  17. Yes, use a consistent policy for handling messages to and from the
  18. timer device.  Don't go mixing Wait() and GetMsg() with AbortIO()
  19. and WaitIO() unless you pay special attention to what might happen
  20. to the signal (as you found out).  In particular:
  21.  
  22. Wait()      Allways clears signal(s).
  23. WaitIO()    May or may not clear signal, depends on whether
  24.               IO was completed already.
  25. WaitPort()  Like WaitIO(), may or may not clear signal.
  26. AbortIO()   Might result in signal being set if the IO had not
  27.               already completed.  Leaves signal unchanged otherwise.
  28. SendIO()    Appears not to affect signals, but in fact does
  29.               leave signal clear.
  30. DoIO()      No appearant effect on signals.
  31.  
  32. Note that most of the time you really don't know the state of
  33. a signal after one of these calls.  Program defensively, being
  34. prepared for every case.
  35.  
  36. Note that the signal associated with the reply port (or any other
  37. port for that matter) is optional.  Note as well that the reply port
  38. itself is optional.  Nobody does IO without a reply port and an
  39. associated signal, though.
  40.  
  41. >My query is:  Why is the signal still active after AbortIO and WaitIO? 
  42. >What do I need to do to reset it?
  43.  
  44. WaitIO() doesn't always clear out the signal bit.  In fact, nothing but
  45. Wait( 1L<<SigBit ) and SetSignal( 0, 1L<<SigBit ) are guaranteed
  46. to clear them out, and the bits are not guaranteed to stay cleared,
  47. even as long as until the next line of code.  (ppp #247: Any task 
  48. in the system is free to set any of your signals at any moment.
  49. You should be prepared for that.)  (ppp=paranoid programmer pragma)
  50.  
  51. We tend to associate signals too closely with other things--messages
  52. coming in, etc., but that's a mistake.  Signals only really mean
  53. that a signal is set.  You should program as if signals are only
  54. suggestions that perhaps some events might have happend and
  55. that perhaps it would be a good thing to check on them but don't
  56. be surprised if it's a false alarm.
  57.  
  58. You could clear the signal before you send your timer message.
  59. "SetSignal( 0, 1L << TimerMP->mp_SigBit )" would do it.  However,
  60. SetSignal() is documented as being "considered dangerous" whatever
  61. that means.
  62. --
  63.  _/_/_/  _/     Todd_Lewis@unc.edu          You can lead a horse to 
  64.   _/    _/     utoddl@guitar.oit.unc.edu   Mohammad, but you can't make
  65.  _/    _/_/_/                             a mountain drink a mole hill.
  66.