View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000883 | 1003.1(2013)/Issue7+TC1 | System Interfaces | public | 2014-10-14 19:14 | 2022-07-25 15:49 |
| Reporter | nevion | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | Closed | Resolution | Rejected | ||
| 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. | ||||
|
|
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. |
|
|
Since there has been no activity since the procedures in SD6 were provided, this bug is rejected. |
| 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 | |
| 2022-07-25 15:49 | geoffclare | Interp Status | => --- |
| 2022-07-25 15:49 | geoffclare | Note Added: 0005910 | |
| 2022-07-25 15:49 | geoffclare | Status | New => Closed |
| 2022-07-25 15:49 | geoffclare | Resolution | Open => Rejected |
