Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000883 [1003.1(2013)/Issue7+TC1] System Interfaces Editorial Enhancement Request 2014-10-14 19:14 2015-01-30 11:42
Reporter nevion View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Jason Newton
Organization
User Reference
Section n/a
Page Number n/a
Line Number n/a
Interp Status ---
Final Accepted Text
Summary 0000883: Provide Robust pthread_rwlock_t modifiers
Description A wart with rwlocks at the moment is that rwlocks can be cross process like pthread_mutex_t but not robust, unlike pthread_mutex_t.

This issue seeks to rectify the situation to provide cross process robust rwlocks.


This is my first issue raised to this tracker - I tried to join the austin group mailing list for discussion there but the registration site is having some issues creating new individuals.
Desired Action provide the following apis and cloned behavior of robust mutex's:

int pthread_rwlockattr_getrobust(const pthread_rwlockattr_t *restrict
       attr, int *restrict robust);
int pthread_rwlockattr_setrobust(pthread_rwlockattr_t *attr,
       int robust)

Operations on rwlocks owned by dead processes should return the error EOWNERDEAD, like robust mutexes.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0002532)
ajosey (manager)
2015-01-30 11:42

The Austin Group has a set of established procedures for the specification which have to be followed for the addition of new APIs.

These are documented in http://www.opengroup.org/austin/docs/austin_sd6.txt [^]

The summary is that new APIs are out of scope, unless specific criteria are met.

I enclose the applicable text extract below with the full details

----start quote----
New Work Items


From time to time, a defect report may propose new work
items that are outside the scope of maintenance of the Austin Group
specifications. This section addresses how these are handled.

The Austin Group is not a development body for new material apart from
integration issues arising from the merger of the approved standards
that were the Base documents into the revision.

The Austin Group expects to take a similar approach for a future revision.
Thus if a defect report raises the possibility of new interfaces
for inclusion, the standard response will be that it is out of scope
for either a TC or Interpretation, and that if the new material were
to meet the some criteria it may be considered for inclusion in a
future revision subject to the agreed scope determined at that time,
although there is no guarantee.

The recommended criteria for development of new interfaces to enable
them to be considered for inclusion in a future revision are as follows:

1.There must be a written specification that has undergone a formal
consensus based approval process and is suitable for inclusion.

Parties interested in submitting new work items through one of the
three organizations within the Austin Group (The Open Group, IEEE, ISO/IEC)
should contact the appropriate Organizational Representative for further
information and advice on how each organization handles new work items.
Submissions from other organizations will also be considered.
Items 2 through 4 below apply to all submissions regardless of
origin.

2.There must be an implementation, preferably a reference implementation.

3.The specification must be "sponsored" by one of three organizations
(The Open Group, IEEE, ISO/IEC) within the Austin Group, i.e. they would
support and champion its inclusion.

4.Submitters must provide an outline plan of the editing instructions to
merge the document with the Austin Group specifications, and assistance
to the Austin Group editors as required to complete the merger.
For an example, see

https://collaboration.opengroup.org/platform/single_unix_specification/protected/mailarch.php?soph=N&action=show&archive=austin-group-l&num=434 [^] [^]

or
https://collaboration.opengroup.org/sophocles/mailarch.php?soph=Y&action=show&archive=austin-group-l&num=434 [^] [^]


---end quote---

Please followup if there is additional information the standard developers should take into consideration.

- Issue History
Date Modified Username Field Change
2014-10-14 19:14 nevion New Issue
2014-10-14 19:14 nevion Name => Jason Newton
2014-10-14 19:14 nevion Section => n/a
2014-10-14 19:14 nevion Page Number => n/a
2014-10-14 19:14 nevion Line Number => n/a
2015-01-30 11:42 ajosey Note Added: 0002532


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker