pc@hillside.co.uk (Peter Collinson) (04/13/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson)
An Update on UNIX-Related Standards Activities
1003.5: Ada Bindings
USENIX Standards Watchdog Committee
Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
April 12, 1991
Jayne Baker <cgb@d74sun.mitre.org> reports on the January
7-11, 1991 meeting in New Orleans, LA:
1. Introduction
The Ada Language Binding to the POSIX 1003.1 Base Specification
(P1003.5) is moving through the IEEE ballot process.
Now that ballot resolution has begun, the P1003.5 working group no
longer exists; we are now the P1003.5 Ballot Resolution Group. We
spent the New Orleans meeting doing just that -ballot resolution-
addressing issues from our first ballot, chapter by chapter. This is
no small task, so we also held an interim meeting, February 20 - 22,
near Washington, D.C.
This report outlines some issues from the first round of balloting,
and touches on both potential future Ada work, and our attempts to
spread the P1003.5 word.
2. Ballot Resolution Issues
Here's who is responsible for specific sections of the P1003.5 binding:
Mitch Gart/Alsys Section 1 General
Steve Schwarm/DEC Section 2 Terminology and General
Requirements
Ted Baker/Florida State Section 3 Process Primitives
Steve Deller/Verdix Section 4 Process Environment
Jim Lonjers/Unisys Section 5 Files and Directories
Mitch Gart/Alsys Section 6 Input and Output Primitives
Steve Schwarm/DEC Section 7 Device- and Class-Specific
Functions
Jim Moore/IBM Section 8 Language-Specific Services for Ada
Dave Emery/MITRE Chapter 9 System Databases
And here are some things I found particularly interesting in the
discussions they led.
2.1 Naming Convention Issues
One global issue, more editorial than technical but that drew many
ballot comments and objections, was our lack of a
procedure-and-function-naming convention. We left names to the
individual chapter authors, promising ourselves that we would address
this issue later in document development. We never really did, but
Bevin Brett/DEC proposed a naming convention before New Orleans via
electronic mail, with these guidelines:
- Eliminate multiple names with same meaning by picking one (e.g.,
change ``bad,'' ``invalid,'' etc. to ``bad'');
- Eliminate lengthy prefixes (e.g., change ``POSIX Process
Primitives Process Template'' to ``Template'');
- Make the parameter and subtype names the same.
Unfortunately, he also restructured packages liberally. We worried
about making such sweeping changes after balloting had begun, but
adopted several of his recommendations. Bevin agreed to revise his
proposal, incorporating the changes accepted by the group. Chapter
authors will evaluate the revised proposal. Accepted naming changes,
supported by official ballot comments, will be incorporated into the
document.
2.2 I/O Units
At least one balloter requests we use ``byte'' instead of ``I/O
unit,'' since an I/O unit is both ``large enough to hold any member of
the basic execution character set'' and ``>= 7 bits.'' Another goes
farther, arguing that if ``I/O unit'' is exactly same as C's ``char''
we should eliminate confusion by saying so. A third balloter requests
that POSIX, C, and Ada character sets be somehow unified.
2.3 Signals Discussion
Many balloters objected to signal semantics.
In the current, balloted draft (Draft 6) signals are interrupt entries
and include semantics for interrupt delivery.
P1003.4a uses a SIGWAIT model with a single procedure equivalent to
the Ada delay statement. Our current model may only support
per-process signals, not per-thread signals, i.e., a subset of
P1003.4a. Should we try to develop an approach to signals that does
not break P1003.4a and P1003.4a/Ada?
We also need to review P1003.4's new signal proposal carefully to
decide how much to change the P1003.5 binding to accommodate it. We
do not know how balloters will react to such changes. Some balloters
do not want signals tied to Ada tasks, because they want to use
signals without using tasks. We could provide this, but others think
signals without tasks is absurd. We continue to work on this.
2.4 File Descriptor Types
File descriptor types are controversial. Balloters are divided on
alternatives. Should file descriptors be private types? limited
private types? integers? Each has its advocates. Here are sample
arguments for making file descriptors private:
- Arithmetic operations are available for integer types. Does it
make sense to perform additions on file descriptors?
- Sockets and 1003.4 memory-mapped files are used like file
descriptors but may not be implemented as small integers, even in
C;
- In V.4 the file descriptor limit has gone from 20 to some high
number (4K?), making arrays of file descriptors less practical.
(Array indexing with file descriptors is arguably bad C
programming style anyway.)
Despite such arguments, we left file descriptors integer types because
of the P1003.1 standard (note the definition of dup(2)). We noted in
the rationale that we could have made file descriptors a private Ada
type, required that they look like integers, and included special
operations to disallow arithmetic functions on them, but the group
thought that this would be too cluttered. File descriptors are
acceptably close to integers.
2.5 Blocking Behavior
Tasks are a major source of complaints for Unix Ada users. No one
wants a whole process to block when one task within that process
performs I/O or waits for a file lock. Unfortunately, P1003.1 doesn't
support threads; blocking blocks an entire process, so our document
provides support for per-process blocking. Should it also provide
per-task blocking? Making implementors provide both behaviors could
prove the wrong decision once POSIX supports threads.
After some discussion, two models for blocking were proposed:
- the knife-switch model, and
- the file model.
A knife-switch-model implementation elects either program blocking on
I/O or task-level blocking on I/O for all files. Only one is
supported. A file-model implementation selects either task- or
program-level blocking for I/O on a per-file basis.
Mitch Gart suggested we relax our text in several places to allow
alternative behaviors. He argued that separate predicates for
blocking or non-blocking behavior are unnecessary because users will
specify one or the other when files are opened; on the other hand,
each system should provide an inquiry function that returns the
blocking behaviors it supports.
We will add a statement to the normative conformance definition
section (got all that?) saying that a strictly conforming application
SHALL NOT depend on either task blocking or program blocking.
3. Future Work
3.1 Test Assertions for Current Work
To become an IEEE standard, the P1003.5 document must include test
assertions. Jim Leathrum/Clemson University and his graduate students
have volunteered to develop a set. We like this is approach, because
the assertion writers will lack the working group's preconceptions and
biases. Also, we won't have to do the work and it frees the working
group to press forward to other important POSIX/Ada tasks. We are
well into the ballot process, and will probably defer the test
assertions to a separate document.
3.2 Ada Binding to Shells and Utilities (P1003.2)
Dave Emery continues to develop the Ada binding to P1003.2.
3.3 Ada Binding to Real-Time Extensions to POSIX (P1003.4)
Mars Gralia/Johns Hopkins University offered to put together an
Ada/P1003.4 Project Authorization Request (PAR) broad enough to cover
both the P1003.4 and .4a work. Ted Baker (former .5 snitch)
generously provided the paper, ``Realtime Extension for Portable
Operating Systems Ada Binding,'' some months back, which we will use
as a starting point. We are currently refining a schedule to include
in the PAR.
4. Spreading the P1003.5 Word in Europe
In my last Snitch Report, I said that our group is making a real
effort to educate people about the coming POSIX Ada Language Binding
Standard. Dave Emery/MITRE submitted a team proposal for a tutorial
at Ada Europe in Athens, Greece. It was accepted and scheduled as a
half-day session for May 17, 1991. Unfortunately, we will probably
cancel it because travel to Greece is currently discouraged.
Volume-Number: Volume 23, Number 30