|| ||Andrew Josey <ajosey-AT-rdg.opengroup.org>|
|| ||The Open Group developing New API sets|
|| ||Fri, 17 Feb 2006 07:06:28 GMT|
The Open Group's Base Working Group is developing four new sets of
APIs for consideration as input into the next revision of the Austin
Group joint standard (IEEE Std POSIX 1003.1 and The Open Group Base
Specifications). This email provides a brief overview of these
These are currently out for review. For instructions on how to
obtain the drafts and comment see
The purpose of these new Technical Standards is to define additional
sets of New API Extensions to further increase application capture and
hence portability for systems built upon version 3 of the Single UNIX
Overview of the Extended API Set Part 1
The Extended API Set Part 1 is expected to consist of twenty-five
new system interfaces, and one extension to the ls utility. It also
introduces the concept of a stream associated with a memory buffer
to eliminate may of the errors encountered in the construction
of strings, notably overflowing of strings.
The system interfaces are as follows (listed by header):
Overview of the Extended API Set Part 2
The Extended API Set Part 2 is expected to consist of sixteen
new system interfaces.
The set of interfaces includes:
The motivation for the introduction of this set of interfaces is as
* Interfaces taking a path name are limited by the maximum length of
a path name(_SC_PATH_MAX). The absolute path of files can far exceed
this length. The current solution would be to change the working
directory and use relative path names. This is not thread-safe.
* A second motivation is that files accessed outside the current
working directory are subject to attacks caused by the race condition
created by change any of the elements ofthe path names used.
* A third motivation is to allow implementing code which uses a
virtual current working directory for each individual thread. In
the current model there is only one current working directory for
The new interfaces solve these issues by duplicating existing interfaces
using path names with one change, that is an additional parameter. This
additional parameter must be a file descriptor for a directory. The
operations will then work relative to the specified directory instead
of the current working directory whenever the later would be accessed.
Overview of Extended API Set 3
This proposed set of changes introduces the concept of
Robust mutexes which allow for recovery from some failure situations
when programming with threads.
This includes the addition of robust mutexes and two new
It also includes some additions to existing interfaces:
Overview of Extended API Set 4
The locale model currently used in POSIX and the Single UNIX Specificatoin
was designed at a time when threads were not used at all or at least
were just appearing. Therefore the interface to the locale information
was designed like many other interfaces with process-global access.
This has become a problem now that threads are widely deployed. For other
programming languages (C++, Java) the language designers thought about
this problem in advance and standardized a locale model which can be
used in multi-threaded applications.
This set of changes proposes an extension to POSIX to enable the use of
locales in multi-threaded applications and for implementations of the
locale models in C++. The goal has been to require as little change in
existing applications as possible to use the new features.
New interfaces include:
Thread-aware versions of existing interfaces include:
Andrew Josey The Open Group
Director, Server Platforms Thames Tower, 37-45 Station Road
Email: a(dot)josey(at)opengroup.org Reading,Berks.RG1 1LX,England
to post comments)