NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/std/unix/413

Internet Message Format | 1992-09-09 | 6.9 KB

Path: sparky!uunet!uunet!not-for-mail
From: [e-mail] (Peter Collinson)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.5: Ada Bindings to POSIX
Date: 9 Sep 1992 14:33:24 -0700
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Lines: 125
Sender: [e-mail]
Approved: [e-mail] (Moderator, Sean Eric Fagan)
Message-ID: <[e-mail]>
NNTP-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
POSIX.5: Ada Bindings to POSIX


Del Swanson <[e-mail]> reports on the July 13-17,
1992 meeting in Chicago, IL :

The POSIX.5 group has been working to produce Ada language bindings to
POSIX standards.  As of June, 1992, the IEEE Standards Committee has
approved the Ada binding to POSIX.1 as a standard, designated
POSIX.5.  It should be published as an IEEE standard by the end of the
year.  Congratulations all around to the working group, the ballot
resolution committee, the balloters, and all the supporting employers,
spouses, lovers, etc.

At this time, it is not expected that this document will become an ISO
standard, because of its format and derivation.  POSIX.5 is a
``thick'' binding: it can be read by itself, since it duplicates the
descriptions of all the functions, in addition to describing how they
relate to the Ada language.  And POSIX.5 is derived from the POSIX.1 C
binding, since no Language Independent Specification (LIS) yet
exists.  ISO requires that language bindings be ``thin,'' not
duplicating any information present in the base document, and that
they be bindings to an LIS.

TCOS-SS (the IEEE committee responsible for all POSIX standards) had
previously agreed that POSIX.5 could be approved as an IEEE standard
in its current form. It would not be submitted for ISO
standardization.  A new version of the standard (which will then be
submitted for ISO standardization) will be produced after the LIS is
approved, and after the revision of the Ada language, now expected to
be finalized in 1994.

Meanwhile, there has been a reaction from the European community, and
from members of ISO Working Group 9 (on Ada) that there should be an
Ada binding of POSIX officially sanctioned by ISO.  At the July POSIX
meetings, therefore, we recommended to TCOS-SS that it recommend to
ISO Working Group 15 (ISO POSIX) that POSIX.5 be approved as an ISO
``Committee Document.''

Now that the IEEE standard has been approved, it is incumbent upon the
group to resolve interpretation questions.  Officially, this involves
the formation of an interpretation committee (on which nearly the
entire group sits).  The intent is to explain interfaces, elaborate
semantic descriptions, and define the implications of problematic
interface specifications.  About ten interpretation requests have been
received to this point.  The TCOS approach is that this interpretation
group adds nothing normative to the standard, even by logical
extension.  Any such specifications must be done by balloted revisions
to the document.

The major current activity of the group is the development of bindings
to the Real-Time Extensions standards being developed by the POSIX.4
group.  The binding to POSIX.4 will be relatively straightforward.
This is especially true since a draft thin binding to POSIX.4 has been
prepared by one of our members at Florida State University with
financing from the U.S. Army.

This draft has now been updated a couple of times by the group, and is
ready to be massaged into IEEE format, with a few changes reflecting
the latest POSIX.4 draft.  This POSIX.20 draft 1 is planned to be
circulated for mock ballot after the October meetings.  Our goal is to
have POSIX.20 approved as a standard hard on the heels of POSIX.4 LIS.

This schedule is somewhat of a change from our previous assumption
that we would produce a unified binding to POSIX.4 and POSIX.4a
(threads extensions).  Our current direction is to proceed directly
with balloting the binding to POSIX.4, and work concurrently on the
binding to POSIX.4a.  The advantages are that this reflects the
document structure of the POSIX.4 group, that this approach will fill
the needs of some users sooner, and that the approval of the POSIX.4a
standard is likely to be significantly later than POSIX.4.

Meanwhile, we have also agreed to assist in the production of the
POSIX.4 LIS.  The new technical editor of this document has been a
joint member of the POSIX.4 and the POSIX.5 groups.  The members of
the POSIX.5 group are committed to help him and the POSIX.4 group to
produce the LIS as quickly as possible.

The production of a binding to POSIX.4a is going to be significantly
more complex, because of the interplay of two separate modes of
intra-process concurrency, Ada tasks and POSIX threads.  Complicating
the issues is a difference of philosophy among members of the group,
which is probably reflective of the community at large.

A key question that differentiates the philosophies: should operating
system functions be visible in a binding if the language itself
provides parallel functionality?  Several other issues ensue.  Should
functions be visible that, if called directly, may interfere with the
assumptions and operations of the language support library?  Would it
be acceptable to isolate such functions to emphasize their danger?  Is
it adequate (or acceptable) to assume that Ada compilers will allow
calling such functions via language interface conventions?

One of the greatest technical challenges to the POSIX.4a binding is to
determine the implications of interactions among processes in a
multi-language environment.  The feasibility of mapping tasks to
threads is being demonstrated in prototype implementations.  But some
potential conflicts caused by the interactions of the two entities are
becoming apparent.

We are assuming that these conflicts must be resolved, since at a
minimum Ada programs will want to make use of libraries written in C,
such as GUI and DBMS packages.  We are starting to catalog such
potential conflicts, which revolve around the creation and destruction
of threads/tasks, parent-child relations of threads/tasks, and the
handling of exceptional conditions.  We have barely begun the
resolution process.

Meanwhile, members of our group are involved with two efforts that are
prototyping implementations of Ada bindings to the Real-Time
Extensions (including threads).  As it happens, this is not only being
valuable input to our effort, but a few problems have been found with
the base document drafts, that have been passed on to POSIX.4.

In preparation for the next meeting, we have volunteers to analyze
issues with task/thread interactions, and to propose directions and
bindings to synchronization and scheduling functions.  We hope for
significant progress on these issues, as well as completing
preparations for the mock ballot.

Volume-Number: Volume 29, Number 25