home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18176 < prev    next >
Encoding:
Text File  |  1993-01-05  |  2.9 KB  |  63 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!ninja!zowie.zso.dec.com!ridder
  3. From: ridder@zowie.zso.dec.com (Hans)
  4. Subject: Re: RKM description of WaitPort()
  5. Message-ID: <1993Jan5.193827.23221@ninja.zso.dec.com>
  6. Sender: news@ninja.zso.dec.com (USENET News System)
  7. Nntp-Posting-Host: zowie.zso.dec.com
  8. Organization: Digital Equipment Corporation - DECwest Engineering
  9. References: <1993Jan1.221013.26070@urbana.mcd.mot.com> <1ib7peINNele@uwm.edu>
  10. Date: Tue, 5 Jan 1993 19:38:27 GMT
  11. Lines: 50
  12.  
  13. In article <1ib7peINNele@uwm.edu> bloc1469@ee.ee.uwm.edu (Gregory R Block) writes:
  14. >In article <1993Jan1.221013.26070@urbana.mcd.mot.com> qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes:
  15. >>It seems to me to OS is waking up the task before it has attached the
  16. >>message to the specified port and it would be up the the application
  17. >>to spin on the GetMsg() call until the message generating the signal
  18. >>showed up.
  19. >
  20. >No, it's just possible to send a signal to a port without sending a
  21. >message.
  22.  
  23. There is a much more likely cause of a signal bit being set without
  24. there being a message.  It probably occurs *very* frequently which is
  25. the reason programs break quite quickly if message processing isn't done
  26. correctly.  The sequence of events goes like this (pay attention now
  27. ;-):
  28.  
  29. Your task calls Wait() with the signal bit for a message port.  A
  30. message (such as an IntuiMsg) arrives at your message port causing the
  31. signal bit to be set, thus waking your task.  The Wait() returns after
  32. clearing the signal bit.  Your task enters the usual loop calling
  33. GetMsg() until NULL is returned.  While your task is processing
  34. messages, a higher priority task (like the input.device task) or an
  35. interrupt preempts your message processing loop and winds up placing
  36. another message on your port, setting your signal bit again.  Your task
  37. is resumed, and you continue processing *all* the messages, including
  38. the one which just caused your signal bit to be set.
  39.  
  40. Note that emptying a message port does *not* clear the corresponding
  41. signal bit (since other ports may be sharing the same signal bit.)  Now
  42. with the message port empty your task calls Wait() again, which
  43. immediatly returns due to the signal bit being set.  There are however,
  44. no messages to be processed....
  45.  
  46. Therefore, you *must* be sure to check the return from GetMsg() for
  47. NULL, *even if* you just returned from a Wait() indicating a message has
  48. arrived.  
  49.  
  50. In any case, the wording in the Autodocs is at best completly
  51. misleading, and more likely just plain wrong.  I can't imagine any
  52. circumstance where the signal bit will be set, but the message has not
  53. arrived on the port *yet*.  I welcome any discussion to the contrary.
  54.  
  55. >Greg
  56.  
  57. -hans
  58. -- 
  59.   Hans-Gabriel Ridder <ridder@rust.zso.dec.com>
  60.   DECwest Engineering, Bellevue, Washington, USA
  61.   "I'd rather be writing MACRO-20!"
  62.   Any opinions expressed are not those of my employer, honest.
  63.