Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/reports/1988.12/text0006.txt

Text File | 1989-01-07 | 5.8 KB | 149 lines

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]


      An update on UNIX|= Standards Activities - Part 7

                    POSIX 1003.5 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.5 - Ada Language Binding

This group is interesting.  They have now distributed draft
1 of their standard to the working group, but they are very
close to finishing.

The primary goal of the P1003.5 working group is to produce
an Ada language binding for the operating system services
interface defined by the P1003.1 standard.  This work has
progressed to the stage of circulating draft chapters within
the group.  These chapters are to be reviewed at the next .5
meeting (in January).

The last .5 meeting was 7-9 September 1988 in Minneapolis,
Minnesota.  One of the issues discussed there was improving
coordination with the rest of P1003.  The last two P1003
meetings conflicted with major Ada meetings, so that .5
chose to meet separately.  This has not been good for
communication.  Fortunately, there are no major conflicts
with the Fort Lauderdale meeting, and we will attempt to
synchronize future meetings with the rest of the P1003
working groups.

Major issues which were discussed at the September meeting
included: (1) the relationship of Ada I/O and POSIX I/O, and
how this relates to P1003.0; (2) (missing) support for Ada
in the P1003.2 standard; (3) real-time features required by
Ada, and whether P1003.4 will provide these; (4) changes to
.1 between draft 12 and the final version that will require
changes to the .5 draft chapters; (5) the relationship of
Ada tasks to POSIX processes; (6) whether the organization
of the P1003.5 document should mirror the .1 document.

One of the central problems they face is reconciling the
relationship between Ada tasks and POSIX processes.  Unlike
POSIX processes, Ada tasks share a common logical address

__________

  |= UNIX is a registered trademark of AT&T in the U.S. and
    other countries.


                           - 2 -

space.  If they map Ada tasks onto distinct POSIX processes,
they need a way to share memory and file handles (opened
after fork) between processes, which is not provided in .1.
(Support for shared memory is on the .4 agenda, but the
final form remains uncertain.)  Moreover, there are
applications of Ada tasks that require task switching,
creation, and termination to be performed much faster than
may be possible for POSIX processes.

On the other hand, we might implement tasks as multiple
threads of control within a process, but then they run into
other problems.  Unfortunately, multiple threads of control
within a process cannot be supported well without some
cooperation from the OS.  For example, a blocking system
call by one thread should not block other threads.  For
another example, what happens when one task is in the middle
of a system call and another one forks?  (For now, P1003.5
agreed that Fork/Exec should be allowed, but that their
effects in a multitasking Ada program are implementation
dependent.)

The concept of POSIX support for "light-weight processes" is
appealing.  The group will explore the applicability of such
a solution.  In order to broaden the base of interest, we
have agreed to sponsor a "Birds of a Feather" discussion on
this issue at the Ft.  Lauderdale meeting.

Another major problem is reconciling POSIX signals with Ada
semantics.  The .5 group has done some preliminary work on
this.  The concept most closely corresponds to an
asynchronous Ada exception, but this construct is of
questionable legality.  The legal Ada mechanism appears to
be entry calls, but this presents other problems.  Much work
remains.

A third problem area is data representation, and character
sets in particular.  POSIX already has problems with
international character sets, arising from special uses of
certain glyphs, and from an implicit assumption that
characters are represented as bytes.  Ada makes this worse,
since it specifies a very specific standard character set
(ASCII).  The .5 group proposes to recognize POSIX
characters (and strings) as distinct from the Ada versions,
and to provide transfer functions for situations where one
must be converted to the other.

Due to a comflict with the ACM Tri-Ada conference, 1003.5
was not able to meet with the rest of the POSIX committees
in Hawaii.  However, several individual members volunteered
to attend as liaison with the other groups.  This will
probably turn out to have been very helpful in resolving


                           - 3 -

some questions about division of responsibility.  The
Watchdog Committee contact met with both 1003.1 and 1003.4
during the week.

It became clear during the 1003.1 meeting that but should
move ahead boldly to create a true Ada interface.  Further,
it appeared that due to Ada's strong typing requirements
(required by ISO) than the present .1 standard, and might
well influence the form of the future .1.

Meetings with the .4 revealed that support for Ada's real-
time requirements might be provided by that group, but not
necessarily in a suitable form or soon enough.  In
particular, the subject of lightweight processes, which
might be used to implement Ada tasks, is not on the .4
agenda.  This leaves the subject open to be addressed by .5.

These, and observations by other .5 members serving as
liaisons are likely to influence the direction of work when
the group next gets together.

The Watchdog committee contact for 1003.5 is Ted Baker.  He
can be reached at:

          Ted Baker
          Department of Computer Science
          Florida State University
          Tallahassee, FL 32306
          [phone]
          [e-mail]
          [e-mail]


Volume-Number: Volume 15, Number 43