Path: utzoo!utgpu!watmath!clyde!att!ulysses!andante!mit-eddie!rutgers!cs.utexas.edu!longway!std-unix From: ahby@bungia.bungia.mn.org (Shane P. McCarron) Newsgroups: comp.std.unix Subject: Standards Update, Part 7: IEEE 1003.5 Message-ID: <275@longway.TIC.COM> Date: 12 Dec 88 08:00:11 GMT Sender: std-unix@longway.TIC.COM Reply-To: Shane P. McCarron Lines: 147 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) [ These Standards Updates are published after each IEEE 1003 meeting, and are commissioned by the USENIX Association. See Part 1 for contact information. -mod ] An update on UNIX|= Standards Activities - Part 7 POSIX 1003.5 Update November 18, 1988 Shane P. McCarron, NAPS International 1003.5 - Ada Language Binding This group is interesting. They have now distributed draft 1 of their standard to the working group, but they are very close to finishing. The primary goal of the P1003.5 working group is to produce an Ada language binding for the operating system services interface defined by the P1003.1 standard. This work has progressed to the stage of circulating draft chapters within the group. These chapters are to be reviewed at the next .5 meeting (in January). The last .5 meeting was 7-9 September 1988 in Minneapolis, Minnesota. One of the issues discussed there was improving coordination with the rest of P1003. The last two P1003 meetings conflicted with major Ada meetings, so that .5 chose to meet separately. This has not been good for communication. Fortunately, there are no major conflicts with the Fort Lauderdale meeting, and we will attempt to synchronize future meetings with the rest of the P1003 working groups. Major issues which were discussed at the September meeting included: (1) the relationship of Ada I/O and POSIX I/O, and how this relates to P1003.0; (2) (missing) support for Ada in the P1003.2 standard; (3) real-time features required by Ada, and whether P1003.4 will provide these; (4) changes to .1 between draft 12 and the final version that will require changes to the .5 draft chapters; (5) the relationship of Ada tasks to POSIX processes; (6) whether the organization of the P1003.5 document should mirror the .1 document. One of the central problems they face is reconciling the relationship between Ada tasks and POSIX processes. Unlike POSIX processes, Ada tasks share a common logical address __________ |= UNIX is a registered trademark of AT&T in the U.S. and other countries. - 2 - space. If they map Ada tasks onto distinct POSIX processes, they need a way to share memory and file handles (opened after fork) between processes, which is not provided in .1. (Support for shared memory is on the .4 agenda, but the final form remains uncertain.) Moreover, there are applications of Ada tasks that require task switching, creation, and termination to be performed much faster than may be possible for POSIX processes. On the other hand, we might implement tasks as multiple threads of control within a process, but then they run into other problems. Unfortunately, multiple threads of control within a process cannot be supported well without some cooperation from the OS. For example, a blocking system call by one thread should not block other threads. For another example, what happens when one task is in the middle of a system call and another one forks? (For now, P1003.5 agreed that Fork/Exec should be allowed, but that their effects in a multitasking Ada program are implementation dependent.) The concept of POSIX support for "light-weight processes" is appealing. The group will explore the applicability of such a solution. In order to broaden the base of interest, we have agreed to sponsor a "Birds of a Feather" discussion on this issue at the Ft. Lauderdale meeting. Another major problem is reconciling POSIX signals with Ada semantics. The .5 group has done some preliminary work on this. The concept most closely corresponds to an asynchronous Ada exception, but this construct is of questionable legality. The legal Ada mechanism appears to be entry calls, but this presents other problems. Much work remains. A third problem area is data representation, and character sets in particular. POSIX already has problems with international character sets, arising from special uses of certain glyphs, and from an implicit assumption that characters are represented as bytes. Ada makes this worse, since it specifies a very specific standard character set (ASCII). The .5 group proposes to recognize POSIX characters (and strings) as distinct from the Ada versions, and to provide transfer functions for situations where one must be converted to the other. Due to a comflict with the ACM Tri-Ada conference, 1003.5 was not able to meet with the rest of the POSIX committees in Hawaii. However, several individual members volunteered to attend as liaison with the other groups. This will probably turn out to have been very helpful in resolving - 3 - some questions about division of responsibility. The Watchdog Committee contact met with both 1003.1 and 1003.4 during the week. It became clear during the 1003.1 meeting that but should move ahead boldly to create a true Ada interface. Further, it appeared that due to Ada's strong typing requirements (required by ISO) than the present .1 standard, and might well influence the form of the future .1. Meetings with the .4 revealed that support for Ada's real- time requirements might be provided by that group, but not necessarily in a suitable form or soon enough. In particular, the subject of lightweight processes, which might be used to implement Ada tasks, is not on the .4 agenda. This leaves the subject open to be addressed by .5. These, and observations by other .5 members serving as liaisons are likely to influence the direction of work when the group next gets together. The Watchdog committee contact for 1003.5 is Ted Baker. He can be reached at: Ted Baker Department of Computer Science Florida State University Tallahassee, FL 32306 +1 904 644-5452 tbaker@ajpo.sei.cmu.edu baker@nu.cs.fsu.edu Volume-Number: Volume 15, Number 43