std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (05/11/89)
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 35dee@linus.MITRE.ORG (David E. Emery) (05/16/89)
Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Return-Path: <dee@linus.MITRE.ORG> To: baker@nu.cs.fsu.edu, std-unix@longway.TIC.COM, shane@bungia.mn.org Cc: posix-ada-committee@grebyn.com From: dee@linus.MITRE.ORG (David E. Emery) Standards Update Part 4: 1003.5 An update on UNIX|= Standards Activities January 1989 IEEE 1003 Meeting, Ft. Lauderdale 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. --------------- I don't think this is a very fair characterization of our working group. It may have been true at Minneapolis (where most of the 1003.5 officers, for various reasons, were unable to attend), but many of us have a pretty solid Unix background. It is true that we sometimes have to educate the 'uninitiated'. It is also true that we need more bodies, particularly people literate in both Unix and Ada. However, there is a substantial interest in Ada on Unix, indicated by the large number of vendors (Verdix, Telesoft, Alsys, Meridian, DDC and Tartan Labs <this list is probably not complete, either>). However, I take significant exception to the implication that the 1003.5 committee "does not understand Unix." This is particularly true when you look at the expressed attitude of the rest of 1003, that "we don't care about Ada", or at best "we don't have time to learn Ada". We have a major problem when Ada and Unix clash, a problem I don't think that the rest of P1003 can appreciate (given their narrow C focus). dave emery@mitre.org [ The report was based on the Minneapolis meeting. It's good to see some counter opinions, though. -mod ] Volume-Number: Volume 16, Number 41