home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / csu.shar / 39 < prev   
Internet Message Format  |  1988-12-19  |  6KB
  1. Path: longway!std-unix
  2. From: ahby@bungia.bungia.mn.org (Shane P. McCarron)
  3. Newsgroups: comp.std.unix
  4. Subject: Standards Update, Part 7: IEEE 1003.5
  5. Message-ID: <275@longway.TIC.COM>
  6. Date: 12 Dec 88 08:00:11 GMT
  7. Sender: std-unix@longway.TIC.COM
  8. Reply-To: Shane P. McCarron <ahby@bungia.bungia.mn.org>
  9. Lines: 147
  10. Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)
  11.  
  12. [ These Standards Updates are published after each IEEE 1003
  13. meeting, and are commissioned by the USENIX Association.
  14. See Part 1 for contact information.  -mod ]
  15.  
  16.  
  17.       An update on UNIX|= Standards Activities - Part 7
  18.  
  19.                     POSIX 1003.5 Update
  20.  
  21.                      November 18, 1988
  22.  
  23.            Shane P. McCarron, NAPS International
  24.  
  25. 1003.5 - Ada Language Binding
  26.  
  27. This group is interesting.  They have now distributed draft
  28. 1 of their standard to the working group, but they are very
  29. close to finishing.
  30.  
  31. The primary goal of the P1003.5 working group is to produce
  32. an Ada language binding for the operating system services
  33. interface defined by the P1003.1 standard.  This work has
  34. progressed to the stage of circulating draft chapters within
  35. the group.  These chapters are to be reviewed at the next .5
  36. meeting (in January).
  37.  
  38. The last .5 meeting was 7-9 September 1988 in Minneapolis,
  39. Minnesota.  One of the issues discussed there was improving
  40. coordination with the rest of P1003.  The last two P1003
  41. meetings conflicted with major Ada meetings, so that .5
  42. chose to meet separately.  This has not been good for
  43. communication.  Fortunately, there are no major conflicts
  44. with the Fort Lauderdale meeting, and we will attempt to
  45. synchronize future meetings with the rest of the P1003
  46. working groups.
  47.  
  48. Major issues which were discussed at the September meeting
  49. included: (1) the relationship of Ada I/O and POSIX I/O, and
  50. how this relates to P1003.0; (2) (missing) support for Ada
  51. in the P1003.2 standard; (3) real-time features required by
  52. Ada, and whether P1003.4 will provide these; (4) changes to
  53. .1 between draft 12 and the final version that will require
  54. changes to the .5 draft chapters; (5) the relationship of
  55. Ada tasks to POSIX processes; (6) whether the organization
  56. of the P1003.5 document should mirror the .1 document.
  57.  
  58. One of the central problems they face is reconciling the
  59. relationship between Ada tasks and POSIX processes.  Unlike
  60. POSIX processes, Ada tasks share a common logical address
  61.  
  62. __________
  63.  
  64.   |= UNIX is a registered trademark of AT&T in the U.S. and
  65.     other countries.
  66.  
  67.  
  68.                            - 2 -
  69.  
  70. space.  If they map Ada tasks onto distinct POSIX processes,
  71. they need a way to share memory and file handles (opened
  72. after fork) between processes, which is not provided in .1.
  73. (Support for shared memory is on the .4 agenda, but the
  74. final form remains uncertain.)  Moreover, there are
  75. applications of Ada tasks that require task switching,
  76. creation, and termination to be performed much faster than
  77. may be possible for POSIX processes.
  78.  
  79. On the other hand, we might implement tasks as multiple
  80. threads of control within a process, but then they run into
  81. other problems.  Unfortunately, multiple threads of control
  82. within a process cannot be supported well without some
  83. cooperation from the OS.  For example, a blocking system
  84. call by one thread should not block other threads.  For
  85. another example, what happens when one task is in the middle
  86. of a system call and another one forks?  (For now, P1003.5
  87. agreed that Fork/Exec should be allowed, but that their
  88. effects in a multitasking Ada program are implementation
  89. dependent.)
  90.  
  91. The concept of POSIX support for "light-weight processes" is
  92. appealing.  The group will explore the applicability of such
  93. a solution.  In order to broaden the base of interest, we
  94. have agreed to sponsor a "Birds of a Feather" discussion on
  95. this issue at the Ft.  Lauderdale meeting.
  96.  
  97. Another major problem is reconciling POSIX signals with Ada
  98. semantics.  The .5 group has done some preliminary work on
  99. this.  The concept most closely corresponds to an
  100. asynchronous Ada exception, but this construct is of
  101. questionable legality.  The legal Ada mechanism appears to
  102. be entry calls, but this presents other problems.  Much work
  103. remains.
  104.  
  105. A third problem area is data representation, and character
  106. sets in particular.  POSIX already has problems with
  107. international character sets, arising from special uses of
  108. certain glyphs, and from an implicit assumption that
  109. characters are represented as bytes.  Ada makes this worse,
  110. since it specifies a very specific standard character set
  111. (ASCII).  The .5 group proposes to recognize POSIX
  112. characters (and strings) as distinct from the Ada versions,
  113. and to provide transfer functions for situations where one
  114. must be converted to the other.
  115.  
  116. Due to a comflict with the ACM Tri-Ada conference, 1003.5
  117. was not able to meet with the rest of the POSIX committees
  118. in Hawaii.  However, several individual members volunteered
  119. to attend as liaison with the other groups.  This will
  120. probably turn out to have been very helpful in resolving
  121.  
  122.  
  123.                            - 3 -
  124.  
  125. some questions about division of responsibility.  The
  126. Watchdog Committee contact met with both 1003.1 and 1003.4
  127. during the week.
  128.  
  129. It became clear during the 1003.1 meeting that but should
  130. move ahead boldly to create a true Ada interface.  Further,
  131. it appeared that due to Ada's strong typing requirements
  132. (required by ISO) than the present .1 standard, and might
  133. well influence the form of the future .1.
  134.  
  135. Meetings with the .4 revealed that support for Ada's real-
  136. time requirements might be provided by that group, but not
  137. necessarily in a suitable form or soon enough.  In
  138. particular, the subject of lightweight processes, which
  139. might be used to implement Ada tasks, is not on the .4
  140. agenda.  This leaves the subject open to be addressed by .5.
  141.  
  142. These, and observations by other .5 members serving as
  143. liaisons are likely to influence the direction of work when
  144. the group next gets together.
  145.  
  146. The Watchdog committee contact for 1003.5 is Ted Baker.  He
  147. can be reached at:
  148.  
  149.           Ted Baker
  150.           Department of Computer Science
  151.           Florida State University
  152.           Tallahassee, FL 32306
  153.           +1 904 644-5452
  154.           tbaker@ajpo.sei.cmu.edu
  155.           baker@nu.cs.fsu.edu
  156.  
  157.  
  158. Volume-Number: Volume 15, Number 43
  159.