home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / v21 / 050 < prev    next >
Internet Message Format  |  1990-12-05  |  5KB
  1. From std-unix-request@uunet.uu.net  Wed Aug 22 12:19:11 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA00733; Wed, 22 Aug 90 12:19:11 -0400
  4. Posted-Date: 22 Aug 90 16:09:13 GMT
  5. Received: by cs.utexas.edu (5.64/1.71)
  6.     id AA05460; Wed, 22 Aug 90 11:19:05 -0500
  7. From: jsh@usenix.org (Jeffrey S. Haemer)
  8. Newsgroups: comp.std.unix
  9. Subject: Standards Update, IEEE 1003.4: Real-time Extensions
  10. Message-Id: <448@usenix.ORG>
  11. Sender: std-unix@usenix.ORG
  12. Reply-To: std-unix@uunet.uu.net
  13. Organization: USENIX Standards Watchdog Committee
  14. X-Submissions: std-unix@uunet.uu.net
  15. Date: 22 Aug 90 16:09:13 GMT
  16. To: std-unix@uunet.uu.net
  17.  
  18. From:  Jeffrey S. Haemer <jsh@usenix.org>
  19.  
  20.  
  21.            An Update on UNIX*-Related Standards Activities
  22.  
  23.                              August, 1990
  24.  
  25.                  USENIX Standards Watchdog Committee
  26.  
  27.           Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
  28.  
  29. IEEE 1003.4: Real-time Extensions
  30.  
  31. Rick Greer <rick@ism.isc.com> reports on the July 16-20 meeting in
  32. Danvers, Massachusetts:
  33.  
  34. Most of the action in the July dot four meeting centered around -- you
  35. guessed it -- threads.  The current threads draft (1003.4a) came very
  36. close to going to ballot.  An overwhelming majority of those present
  37. voted to send the draft to ballot, but there were enough complaints
  38. from the dot fourteen people (that's multiprocessing -- MP) about the
  39. scheduling chapter to hold it back for another three months.
  40. Volunteers from dot fourteen have agreed to work on the scheduling
  41. sections so that the draft can go to ballot after the next meeting, in
  42. October.
  43.  
  44. Actually, dot four voted to send the draft to ballot after that
  45. meeting in any case, and the resolution was worded in such a way that
  46. a consensus would be required to prevent the draft from going to
  47. ballot in October.  Thus, the MP folks have this one final chance to
  48. clean up the stuff that's bothering them -- if it isn't fixed by
  49. October, it will have to be fixed in balloting.  Some of us in dot
  50. fourteen felt the best way to fix the thread scheduling stuff was via
  51. ballot objection anyway.  Unfortunately, the threads balloting group
  52. is now officially closed, and a number of MP people saw this as their
  53. last chance to make a contribution to the threads effort.  The members
  54. of dot fourteen weren't the only ones to be taken by surprise by the
  55. closure of the threads balloting group.  It seems that many felt that
  56. it would be a cold day in hell before threads made it to ballot and
  57. weren't following the progress of dot four all that closely.  [Editor:
  58. I've bet John Gertwagen a beer that threads will finish balloting
  59. before the rest of dot four.  The bet's a long way from being decided,
  60. but I still think I'll get my beer.]
  61.  
  62. Meanwhile, the ballot resolution process continues for the rest of dot
  63. four, albeit rather slowly.  There are a number of problems here, the
  64. biggest being lack of resources.  In general, people would much rather
  65. argue about threads than deal with the day-to-day grunt work
  66. associated with the IEEE standards process.  [Editor: The meeting will
  67.  
  68. __________
  69.  
  70.   * UNIXTM is a Registered Trademark of UNIX System Laboratories in
  71.     the United States and other countries.
  72.  
  73. August, 1990 Standards Update        IEEE 1003.4: Real-time Extensions
  74.  
  75.  
  76.                 - 2 -
  77.  
  78. be in Seattle, Washington.  Go.  Be a resource.] Many of the technical
  79. reviewers have yet to get started on their sections.  Nevertheless,
  80. proposed resolutions to a number of objections were presented and
  81. accepted at the Danvers meeting.
  82.  
  83.      [Editor: Rick is temporarily unavailable, but Simon Patience of
  84.      the OSF has kindly supplied these examples:
  85.  
  86.      The resolved objections were taken from the CRB: replacing the
  87.      event mechanism by ``fixed'' signals, replacing the shared memory
  88.      mechanism by mmap() and removing semaphore handles from the file
  89.      system name space.  Replacing events by signals was accepted; no
  90.      problem here.  Adopting mmap() got a mixed reception, partly
  91.      because some people thought you had to take all of mmap(), where
  92.      a subset might suffice.  The final vote on this was not to ask
  93.      the reviewer to adopt mmap(), which may not not satisfy the
  94.      objectors.  I'd guess the balloting group will eventually hold
  95.      sway here!  Finally, the group accepted abandoning the use of
  96.      file descriptors for semaphore handles, but some participants
  97.      wanted to keep semaphore names pathnames.  The reviewer was sent
  98.      off to rethink the implications of this suggestion.  ]
  99.  
  100. We should be seeing a lot more of this in Seattle.  Similar comments
  101. apply to the real-time profile (AEP) work.  The AEP group made more
  102. progress over the last three months than the technical reviewers did,
  103. although even that (the AEP progress) was less than I'd hoped.  We're
  104. expecting our first official AEP draft in October.
  105.  
  106. August, 1990 Standards Update        IEEE 1003.4: Real-time Extensions
  107.  
  108. Volume-Number: Volume 21, Number 50
  109.  
  110.