Path: utzoo!attcan!uunet!longway!std-unix From: std-unix@longway.TIC.COM (Moderator, John S. Quarterman) Newsgroups: comp.std.unix Subject: Standards Update Part 4: 1003.5 Message-ID: <337@longway.TIC.COM> Date: 11 May 89 15:38:43 GMT Reply-To: std-unix@uunet.uu.net Lines: 238 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) Standards Update Part 4: 1003.5 An update on UNIX|= Standards Activities January 1989 IEEE 1003 Meeting, Ft. Lauderdale Part 4: 1003.5 Shane P. McCarron, NAPS International 1003.5 - Ada Bindings to POSIX This quarter's 1003.5 report points out some problems that are really endemic to the entire standards making process. To wit, the people involved in making standards are rarely those who end up using them. The user community does not (generally) have the wherewithal or time to join standards committees and attend standards committee meetings. POSIX, like all other standards, suffers from this problem. In the case of 1003.5, the problem manifests itself in a new way. While there are few members of the committee, the vendor and end user community are about evenly represented. This would seem to be an advantage. Unfortunately, the Ada vendor and user community is not a UNIX oriented community. The members of this committee, while very knowledgeable about Ada and its requirements, may not be as well verse in traditional UNIX semantics as one would like. This may change as the DoD (and the entire US Federal Government) becomes more interested in POSIX. Until that time, 1003.5 is going to suffer from a dearth of UNIX oriented members. This may cause them to produce a standard that, while strong in Ada terms, is weak when it comes to its relationship to POSIX based systems. The Ada language binding group has a goal of having a standard Ada binding for P1003.1 by the end of 1989, with balloting to take place some time in the fall. The first draft of this standard was available for the January meeting of the POSIX committees, and it is going to take quite a bit of work to get it ready for a fall ballot. This committee is really in desparate need of some warm bodies - preferably with Ada and UNIX backgrounds. __________ |= UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1989 - 1 - Ft. Lauderdale Standards Update Part 4: 1003.5 In addition, they need Ada real-time experts to review the P1003.4 (real-time extensions) draft. 1003.5 will eventually be producing a binding to that standard as well, and it is imperative that all of the semantics that Ada requires of real-time extensions be available. The 1003.4 working group has actually requested that 1003.5 generate responses to some proposals they are considering, but right now they do not have enough people to complete their own work. At the January meeting, the working group started reviewing (and changing) the first draft of the standard, as well as reorganizing their concepts of how POSIX related functions could be grouped logically into Ada packages. The group decided to map POSIX signals onto Ada task entries, following the semantic model established by the Ada standard for interrupts. The discussion narrowed down to three proposals for the way in which a user would express the binding of signal to entry. One major issue is whether it is sufficient for this binding to be specified entirely statically, at compile-time, or whether users will need to be able to rebind dynamically. In the traditional C/UNIX world, rebinding of signals to signal handling functions is used frequently. The other issue was whether signal should only be handleable by tasks of a very simple (generic) form,that handles only one signal, or whether any task should be allowed to have signal-handling entries. The group decided that, from the point of view of the Ada binding, each Ada program execution would consist of a single POSIX process. Implementations might make use of multiple processes at some lower level, but this would not be visible from the POSIX interface. This does not say that a program may not fork, but that the result of a fork operation would be another program execution, rather than another thread (read process, task, etc.) within the same program execution. This has the effect of simplifying the problems presented by signals as well as SUSPEND, RESUME, PAUSE, etc. Perhaps the most interesting issues to come out at the meeting did not involve the draft document directly, but were more global in nature, coming up in combined meetings with other groups. A meeting with the P1003.1 group that is working on the language-independent version of the standard (required by ISO) revealed that the Ada binding group may have been taking too conservative a view with repect to following the C version of the P1003.1 standard. As things evolve, it is January 1989 - 2 - Ft. Lauderdale Standards Update Part 4: 1003.5 acceptable that conformant Ada-POSIX implementations may be incapable of supporting C-POSIX, and vice versa. That is, the language-independent binding will be very abstract. There is no such thing as a POSIX interface without a language binding. Specific language bindings may provide or require functionality not provided by other language bindings. For example, an Ada binding need not directly provide the present POSIX I/O operations. It is appropriate to simply provide the Ada I/O and explain the relationship to POSIX I/O. Similarly an Ada binding might impose additional requirements on system calls to insure correct operation in the presence of multiple threads of control within a process. This may encourage P1003.5 to be bolder, but there remains concern that since the Ada binding is in many instances likely to be implemented "on top" of a C binding, it must not force the Ada programmer to sacrifice any important capabilities, or he will be encouraged to interface directly to the C binding. For the same reason, it is impractical to impose requirements that cannot be implemented via interface to the C binding. Some very vocal members of the P1003.5 group complained bitterly that P1003.1 should provide a memory allocation primitive. (Providing functionality of "sbrk" on some systems, or "malloc" in C.) There are two reasons for this: (1) to implement the Ada "new" allocator; (2) to allow a user to implement his own (more predictable) storage manager, in a portable way. The latter is viewed as important by many Ada users, who are concerned that the Ada language standard does not require an adequate storage allocation and recovery scheme for all applications. Interestingly, the FORTRAN language binding group, which was also in on this discussion, felt the same way, also for reason (2). The position of P1003.1 was hard-line: memory- management is a language implementation function, out of scope of the the POSIX interface. This memory allocation issue came up at an evening meeting with the P1003.4 (Real-time Extensions) working group, with the same position being voiced by P1003.1 representatives. However, P1003.4 members pointed out that they will have an allocation mechanism for shared memory, so that a user could work around the lack of a local memory allocation primitive by using shared memory! (If there is no bread, let them eat cake?) The main reason for the P1003.4/5 meeting was to discuss the issue of multiple threads of control within a process (a.k.a. lightweight processes). Ada runtime system January 1989 - 3 - Ft. Lauderdale Standards Update Part 4: 1003.5 implementors are concerned because they must provide this capability (tasks), and some existing UNIX implementations do not allow this to be done in a satisfactory way. POSIX does not address this problem, and there is no plan to address it in the near future (< 2 years). The memory allocation and multithread issues are part of a more general issue, concerning the scope of POSIX as an end-user application-layer interface, versus an interface that might be useful to language implementors. Ada language and runtime-system implementors would like a POSIX interface sufficiently well defined that their code-generators and runtime systems need not be concerned with details specific to a particular POSIX implementation (beyond the underlying hardware architecture). This is especially true about the implementation of Ada tasking, dynamic storage management, and certain standard packages like the IO packages and Calendar. That is, it would be nice to know that every POSIX implementation would provide the primitives needed to implement Ada. The official (and majority) position on this issue is very clear, though a few vocal individuals remain unhappy with it. Support for language implementations is beyond the scope of POSIX. Ada language implementations will need to make use nonstandard features of particular POSIX implementations. Another interface issue that is of concern to some Ada POSIX group is language interoperability, to the extent of supporting procedure calls from Ada to C, and the ability of Ada programs to read POSIX character files produced by C programs using POSIX I/O, and vice versa. The resolution of this issue is that POSIX will be language-independent, but will not address language interoperability. For example, converting between POSIX strings and Ada strings is an interoperability problem. An Ada binding would simply use Ada strings. The P1003.5 group will exchange proposals by net-mail and meet again with the full POSIX group at the April 1003 meeting in Minneapolis. We will probably have a mock ballot prior to July to be resolved at the July meeting, in San Francisco. The official ballot should immediately follow so that resolution can occur at the October meeting. The USENIX Standards Watchdog Committee contact for 1003.5 is Ted Baker. He can be reached at: Ted Baker Department of Computer Science January 1989 - 4 - Ft. Lauderdale Standards Update Part 4: 1003.5 Florida State University Tallahassee, FL 32306 +1 904 644-5452 tbaker@ajpo.sei.cmu.edu baker@nu.cs.fsu.edu January 1989 - 5 - Ft. Lauderdale Volume-Number: Volume 16, Number 35