Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.16/text0037.txt

Text File | 1989-08-11 | 10.1 KB | 240 lines

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
          [phone]
          [e-mail]
          [e-mail]

January 1989               - 5 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 35