home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0009.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  4.7 KB  |  99 lines
  1. Submitted-by: pc@hillside.co.uk (Peter Collinson)
  2.  
  3. USENIX Standards Watchdog Committee
  4.  
  5. Stephen Walli <stephe@usenix.org>, Report Editor
  6. Report on POSIX.5, POSIX.20: Ada Bindings
  7.  
  8.  
  9. Del Swanson <dswanson@email.sp.unisys.com> reports on the January
  10. 13-17 meeting in Irvine, CA:
  11.  
  12. The POSIX.5 working group is producing an Ada binding to the C-based
  13. POSIX.1 document. The group is also involved with a new project,
  14. POSIX.20.  This will be an Ada binding to the programming language
  15. independent specification of POSIX.4 (Real-time Extensions) and
  16. POSIX.4a (Threads).
  17.  
  18. The meeting in Irvine was spent on the finishing touches to the
  19. POSIX.5 document, which is finishing ballot, and getting a good start
  20. on the new POSIX.20 work.
  21.  
  22. The group had been somewhat shocked at the overwhelming positive
  23. response to the first recirculation of the POSIX.5 document. There was
  24. almost 90% approval by the almost 300 balloters. This is a compliment
  25. to the great ballot resolution job on the part of the technical
  26. reviewers. It was a slight embarrassment, however, since there were
  27. known errors in the draft. In fact, the draft had been sent out for
  28. recirculation even though an error had been discovered at the last
  29. minute. We assumed that it could be fixed in the next recirculation.
  30.  
  31. The group decided to ``do the right thing'', and make one more
  32. recirculation with minor editorial changes and a couple of error
  33. corrections. Draft 8 is expected to be the final recirculation. It
  34. should have a fast turn-around, and it is expected to be approved at
  35. the June meeting of the IEEE Standards Board.
  36.  
  37. Several new members have joined the group because of their interest in
  38. the POSIX.20 binding of the real-time extensions.  They showed
  39. themselves to be eager participants, astute observers, and acquainted
  40. with the issues we will be facing in this task.
  41.  
  42. The single issue that will demand our attention more than any other
  43. during the binding deliberations is how the relationship of Ada tasks
  44. to POSIX.4a threads will be represented in the binding. As background,
  45. most of us are convinced that the p-threads as defined in POSIX.4a will
  46. provide an adequate capability for Ada implementations to use for a
  47. direct mapping of Ada tasks. Further, we believe that the services
  48. provided in the POSIX.4 materials will be sufficient for a reasonably
  49. straight-forward implementation of Ada tasking semantics by Ada
  50. runtime libraries.
  51.  
  52. Nevertheless, the semantics of tasks are not identical to the
  53. semantics of threads (for example, Ada allows no orphans). Further,
  54. since Ada as a language introduces concurrency along with the rules of
  55. interactions, the runtime libraries of Ada implementations like to be
  56. able to make assumptions about the state of tasks. Disrupting this
  57. state would likely be disastrous.  For example, if an application
  58. directly aborted a thread (which had been mapped as a task) the
  59. runtime library could become quickly confused.
  60.  
  61. Opinions about how to deal with this situation range widely, and tend
  62. to be held strongly. Some participants believe that services such as
  63. pthread_create() that are available via language construct (declare a
  64. task) should not be visible to applications by direct call to the
  65. operating system. Others believe that every interface should be made
  66. directly visible by way of the Ada binding. Many attempts are being
  67. made to integrate the needs of the various factions. This issue will
  68. arise in many ways throughout the entire POSIX.20 project.
  69.  
  70. One issue that was resolved was the basic character of the binding.
  71. The IEEE POSIX working groups have taken the lead from ISO WG15 (ISO
  72. POSIX) that all POSIX standards will be formulated as language
  73. independent specifications (LIS), and this will be accompanied by a
  74. series of thin programming language bindings.  While there continues
  75. to be scepticism evidenced by some members of the group, who doubt the
  76. wisdom (or the possibility) of this approach, we agreed that we would
  77. be converts to the cause.
  78.  
  79. We will produce a thin binding to the LIS versions of POSIX.4 and
  80. POSIX.4a.  We will do so enthusiastically. We will help the POSIX.4
  81. working group in so far as we can to produce a viable LIS version.
  82.  
  83. We are fortunate that a couple of our members have received funding to
  84. give us a head start on some labor-intensive activities. The U.S. Navy
  85. funded a solid first draft of the test assertions for POSIX.5. The
  86. U.S. Army funded a first draft thin Ada binding (or transliteration)
  87. of the existing C-based POSIX.4 document.
  88.  
  89. In summary, we are expecting some significant progress at our next
  90. meeting, now that most people are oriented to the issues.  Several
  91. people have volunteered to write position papers, and to start working
  92. on chapters to present for consideration in April.
  93.  
  94. Your Ada Snitch.
  95.  
  96.  
  97. Volume-Number: Volume 27, Number 9
  98.  
  99.