home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0035.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  4.4 KB
  1. From: Jeffrey S. Haemer <jsh@usenix.org>
  2.  
  3.  
  4.  
  5.             An Update on UNIX* and C Standards Activities
  6.  
  7.                             September 1989
  8.  
  9.                  USENIX Standards Watchdog Committee
  10.  
  11.                    Jeffrey S. Haemer, Report Editor
  12.  
  13. IEEE 1003.4: Real-time Extensions Update
  14.  
  15. John Gertwagen <jag@laidbak> reports on the July 10-14, 1989 meeting
  16. in San Jose, California:
  17.  
  18. The P1003.4 meeting in San Jose was very busy.  The meeting focused on
  19. resolving mock-ballot objections and comments. Despite limited
  20. resources for documenting changes, a lot of work got done.  Here's
  21. what stood out.
  22.  
  23. Shared memory
  24.      The preferred interface falls somewhere between shared-memory-
  25.      only and a mapped-files interface, such as AIX's mmap(), which
  26.      allows files to be treated like in-core arrays.  Group direction
  27.      was to reduce the functionality to support only shared memory, so
  28.      long as the resulting interfaces could be implemented as a
  29.      library over mmap().
  30.  
  31. Process memory locking
  32.      The various region locks were clarified and, thus, simplified;
  33.      the old definitions were fuzzy and non-portable.  For those who
  34.      haven't seen it, there is actually a memory residency interface
  35.      (i.e., fetch and store operations to meet some metric) instead of
  36.      a locking interface.  Most vendors will probably implement it as
  37.      a lock, but some may want it to impose highest memory priority in
  38.      the paging system.
  39.  
  40. Inter-process communication
  41.      Members questioned whether the interface definitions could really
  42.      support a broader range of requirements; they're like no others
  43.      in the world today.  Having been designed to meet the real-time
  44.      group's wish list, there are lots of bells and whistles -- far
  45.      more than in System V IPC -- but it's not clear, for example,
  46.      that they are network extensible.  Discussions in these areas
  47.      continue.
  48.  
  49. __________
  50.  
  51.   * UNIX is a registered trademark of AT&T in the U.S. and other
  52.     countries.
  53.  
  54. September 1989 Standards Update      IEEE 1003.4: Real-time Extensions
  55.  
  56.  
  57.                                 - 2 -
  58.  
  59. Events and semaphores
  60.      Members were concerned about possible overlap with other
  61.      mechanisms, especially those being considered for threads. The
  62.      question is basically, "Should there be separate functions for
  63.      different flavors or a single function with multiple options?"
  64.      General sentiment (including our snitch's) seems to be for
  65.      multiple functions; however an implementation might choose to
  66.      make them library interfaces to a common, more general system
  67.      call.  There is, however, a significant minority opinion the
  68.      other way.
  69.  
  70. Scheduling
  71.      Many balloters found process lists and related semantics
  72.      confusing.  An attempt was made to re-cast the wording to be more
  73.      strictly in terms of process behavior.
  74.  
  75. Timers
  76.      Inheritance was brought in line with existing (BSD) practice.
  77.  
  78. Outside of the mock ballot, there were two other major news items.
  79.  
  80. First, there is a movement afoot to make the .4 interfaces part of
  81. 1003.1.  They would become additional chapters and might be voted
  82. separately or in logical groups.  This would bring P1003 in line with
  83. the ISO model of a base standard plus application profiles. POSIX.4
  84. would become the real-time profile group.  This is a non-trivial
  85. change.
  86.  
  87. Up to now, the criterion for .4 has been that of "minimum necessary
  88. for real-time", and has coincidentally been extended to support other
  89. requirements "where convenient".  This is not a good starting point
  90. for a base interface.  For example, mmap(), or something very much
  91. like it, is probably the right base for "shared storage objects", but
  92. real-time users want an interface for shared memory, not for mapped
  93. files.  Our snitch worries that things might look a bit different had
  94. the group been working on a base standard from the beginning.
  95.  
  96. Second, the committee officially began work on a threads interface,
  97. forming a threads small group and creating a stub chapter in the .4
  98. draft.  A working proposal for the interface, representing the
  99. consensus direction of the working group, will be an appendix to the
  100. next draft.
  101.  
  102. A lot of work remains to be done before .4 can go to ballot and the
  103. current January '90 target may not be realistic.  If the proposed re-
  104. organization occurs, a ballot before the summer of 1990 seems unlikely.  
  105.  
  106. September 1989 Standards Update      IEEE 1003.4: Real-time Extensions
  107.  
  108. Volume-Number: Volume 17, Number 40
  109.  
  110.  
  111.