home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / apollo / 3104 < prev    next >
Encoding:
Text File  |  1992-07-24  |  4.7 KB  |  131 lines
  1. Newsgroups: comp.sys.apollo
  2. Path: sparky!uunet!wupost!sdd.hp.com!apollo.hp.com!netnews
  3. From: ganek@apollo.hp.com (Dan Ganek)
  4. Subject: Egg on Face (was Re: Favourite DOMAIN/OS features (or mis-features))
  5. Sender: usenet@apollo.hp.com (Usenet News)
  6. Message-ID: <BrwAII.G7p@apollo.hp.com>
  7. Date: Fri, 24 Jul 1992 13:23:06 GMT
  8. Nntp-Posting-Host: menage_a_trois.ch.apollo.hp.com
  9. Organization: Hewlett-Packard Corporation, Chelmsford, MA
  10. Keywords:  Eventcounts
  11. Lines: 118
  12.  
  13.  
  14.  
  15. Sigh..... A few days ago I posted an article on the correct
  16. way to program eventcounts and as is usually when I
  17. do such a thing, I screwed up. (HP-UX makes eventcount
  18. programming so much easier :-)   So as not to make a 
  19. greater fool of myself, I just post mail I recevied from
  20. Lawrence T. Hoff of Brookhaven.  He not only corrects
  21. my mistake but also gives the alternate way of using event
  22. count (i.e. incrementing the ec value by one instead of using 
  23. ec2_$read)
  24.  
  25. Thanks Laurence, I hope you don't mind.
  26.            
  27. /dan ganek
  28.  
  29. ---BEGIN----
  30.  
  31.     Received:  from bnlux1.bnl.gov by amway.ch.apollo.hp.com id <AA02315@amway.ch.apollo.hp.com> Thu, 23 Jul 92 17:13:57 EDT
  32.     Received:  by bnlux1.bnl.gov (5.57/Ultrix3.0-C)
  33.                id AA11185; Thu, 23 Jul 92 17:12:33 -0400
  34.         Date:  Thursday, July 23, 1992   5:16:35 pm (EDT)
  35.   X-Bad-Date:  Thu, 23 Jul 92 17:12:33 -0400
  36.         From:  hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
  37.           To:  ganek@apollo.hp.com
  38.      Subject:  Re: Favourite DOMAIN/OS features (or mis-features)
  39.   Newsgroups:  comp.sys.apollo
  40.  In-Reply-To:  <BrsrGA.DL8@apollo.hp.com>
  41.   References:  <1992Jul20.093747.12417@wam.umd.edu> <Brozvu.5uu@apollo.hp.com> <1992Jul22.063333.4659@wam.umd.edu>
  42. Organization:  Brookhaven National Laboratory, Upton, NY 11973
  43.  
  44. In article <BrsrGA.DL8@apollo.hp.com> you write:
  45. >
  46. >Second, keeping in mind that I haven't seen the code nor do I have ANY
  47. >idea of the expertise of the author, but this sound like the classic 
  48. >mistake that EVERYONE seems to make when first using eventcounts. (Yours
  49. >truely included). i.e.
  50. >
  51.  
  52. The idea of a 'volatile' value, which can change between statements of sequential
  53. code seems to cause much anxiety among work-station programmers. Folks who
  54. come from a real-time (multi-threaded, w/asynchronous external events ) programming 
  55. background seem to do just fine, tho.
  56.  
  57.  
  58. >instead of the correct sequence, or some CYCLIC variation thereof
  59. >   
  60. >    REPEAT
  61. >      ec2_$wait(..);
  62. >      ec2_$read(..);
  63. >      xxx_$cond_event_wait(...);       
  64. >      process_event(...);
  65. >      UNTIL tired;
  66. >
  67. >the programmer uses something like::
  68. >
  69. >    REPEAT
  70. >      ec2_$wait(..);
  71. >      xxx_$cond_event_wait(...);       
  72. >      {an event can be queued HERE before the ec2_$read but after the cond_event_wait}
  73. >      ec2_$read(..);                   
  74. >      process_event(...);
  75. >      UNTIL tired;  
  76. >
  77.  
  78.     Ummmmmm, good thing you're not going to have to program ec stuff anymore,
  79. you *still* don't have it right. ;-) Actually, your code would work *if*
  80. process_event() dequeued *all* the pending events, *and* didn't choke if there
  81. were no events. In this case it should be called something like process_all_events().
  82.  
  83. Try :
  84.  
  85.     REPEAT
  86.           ec2_$wait(..);
  87.       ec2_$read(..); // to use as new trigger value (+1)
  88.         WHILE (xxx_$cond_event_wait(..))  // must be conditional, because we're 
  89.                                               // *still*  allowing a race condition if 
  90.                                               // new events are queued during processing.
  91.             process_event(..);
  92.       UNTIL tired;
  93.  
  94. Or (better yet) :
  95.  
  96.     REPEAT
  97.       ec2_$wait(..);
  98.       ec2_$read(..); // to use as new trigger value *and* to determine now many 
  99.                          // events to process (new trigger value - old trigger value).
  100.  
  101.          WHILE (number_of_events_to_process)
  102.         number_of_events_to_process -= process_event(..);
  103.  
  104.         // process_events returns the number of events processed, i.e.
  105.         // the number of bytes read from a byte stream or mbx, or always 1
  106.         // for gpr, dialog, unbuffered I/O, datagram events, or other events
  107.                 // which are typically handled one at a time.
  108.  
  109.         // Notice how nothing needs to be 'conditional'
  110.  
  111.       UNTIL tired;
  112.  
  113. Or (even better, but only useful for events which are best handled one at a time)
  114.  
  115.     REPEAT
  116.       ec2_$wait(..);
  117.       trigger_value++; // don't even read the new value, eliminate any chance
  118.                // for a race condition, there's no need for anything
  119.                            // conditional or any looping dequeuing routines.
  120.       process_single_event(..);
  121.  
  122.  
  123. And while we're on the subject, my favorite Domain-ism is/was the variant link.
  124. UNIX users essentially *use* the equivalent of variant links in constructions like :
  125.  
  126. /bin.`arch`
  127.  
  128. but it's not *quite* the same.-- 
  129.  
  130. ----ENDOFMAIL----
  131.