home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0083.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  4.9 KB
  1. From: Jeffrey S. Haemer <jsh@usenix.org>
  2.  
  3.  
  4.             An Update on UNIX* and C Standards Activities
  5.  
  6.                             December 1989
  7.  
  8.                  USENIX Standards Watchdog Committee
  9.  
  10.                    Jeffrey S. Haemer, Report Editor
  11.  
  12. IEEE 1003.4: Real-time Extensions Update
  13.  
  14. John Gertwagen <jag@laidbak> reports on the November 13-17, 1989
  15. meeting in Milpitas, CA:
  16.  
  17. Background
  18.  
  19. The P1003.4 Real-time Working Group, began as the /usr/group technical
  20. committee on real-time extensions.  About two years ago, it was
  21. chartered by the IEEE to develop minimum extensions to POSIX to
  22. support real-time applications.  Over time its scope has expanded, and
  23. P1003.4 is now more a set of general interfaces that extend P1003.1
  24. than a specifically real-time standard.  Its current work is intended
  25. to support not only real-time, but also database, transaction
  26. processing, Ada runtime, and networking environments.  The group is
  27. trying to stay consistent with both the rest of POSIX and other common
  28. practice outside the real-time domain.
  29.  
  30. The work is moving quickly.  Though we have only been working for two
  31. years, we are now on Draft 9 of the proposed standard, and expect to
  32. go out for ballot before the end of the year.  To help keep up this
  33. aggressive schedule.  P1003.4 made only a token appearance at the
  34. official P1003 meeting in Brussels.  The goal of the Milpitas meeting
  35. was to get the draft standard ready for balloting.
  36.  
  37. Meeting Summary
  38.  
  39. Most of the interface proposals are now relatively mature, so there
  40. was a lot of i-dotting and t-crossing, and (fortunately) little
  41. substantive change.  The "performance metrics" sections of several
  42. interface chapters still need attention, but there has been little
  43. initiative in the group to address them, so it looks like the issues
  44. will get resolved during balloting.
  45.  
  46. The biggest piece of substantive work was a failed attempt to make the
  47.  
  48. __________
  49.  
  50.   * UNIX is a registered trademark of AT&T in the U.S. and other
  51.     countries.
  52.  
  53. December 1989 Standards Update       IEEE 1003.4: Real-time Extensions
  54.  
  55.  
  56.                                 - 2 -
  57.  
  58. recently introduced threads proposal clean enough to get into the
  59. ballot.  The stumbling block is a controversy over how to deal with
  60. signals.
  61.  
  62. There are really two, related problems: how to send traditional
  63. UNIX/POSIX signals to a multi-threaded process, and how to
  64. asynchronously interrupt a thread.
  65.  
  66. Four options have been suggested: delivering signals to a (somehow)
  67. privileged thread, per Draft 8; delivering a signal to whichever
  68. thread is unlucky enough to run next, a la Mach; delivering the signal
  69. to each thread that declares an interest; and ducking the issue by
  70. leaving signal semantics undefined.
  71.  
  72. We haven't been able to decide among the options yet; the working
  73. group is now split evenly. About half think signal semantics should
  74. follow the principle of least surprise, and be fully extended to
  75. threads.  The other half think each signal should be delivered to a
  76. single thread, and there should be a separate, explicit mechanism to
  77. let threads communicate with one another.
  78.  
  79. (Personally, I think the full semantics of process signals is extra
  80. baggage in the "lightweight" context of threads.  I favor delivering
  81. signals to a privileged thread -- either the "first" thread or a
  82. designated "agent" -- and providing a separate, lightweight interface
  83. for asynchronously interrupting threads.  On the other hand, I would
  84. be happy to see threads signal one another in a way that looks,
  85. syntactically and semantically, like inter-process signals.  In fact,
  86. I think the early, simpler versions of signal() look a lot like what's
  87. needed (around V6 or so).  I don't care whether the implementation of
  88. "process" and "thread" signals is the same underneath or not.  That
  89. decision should be left to the vendor.)
  90.  
  91. Directions
  92.  
  93. Draft 9 of P1003.4 is being readied for ballot as this is being
  94. written and should be distributed by mid-December.  With a little
  95. luck, balloting will be over by the Summer of '90.
  96.  
  97. Threads is the biggest area of interest in continued work.  The
  98. threads chapter will be an appendix to Draft 9 and the balloting group
  99. will be asked to comment on the threads proposal as if it were being
  100. balloted.  Unless there is a significant write-in effort, the threads
  101. interface will probably be treated as a new work item for P1003.4.
  102. Then, if the outstanding issues can be resolved expediently, threads
  103. could go to ballot as early as April '90.
  104.  
  105. With the real-time interfaces defined, it looks like the next task of
  106. this group will be to create one or more Real-time Application
  107.  
  108. December 1989 Standards Update       IEEE 1003.4: Real-time Extensions
  109.  
  110.  
  111.                                 - 3 -
  112.  
  113. Portability Profiles (RAPPS?) that define how to use the interfaces in
  114. important real-time application models.  Agreeing on the application
  115. models may be harder than agreeing on the interfaces, but we'll see.
  116.  
  117. December 1989 Standards Update       IEEE 1003.4: Real-time Extensions
  118.  
  119.  
  120. Volume-Number: Volume 17, Number 92
  121.  
  122.  
  123.