View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000366 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2010-12-29 02:51 | 2013-04-16 13:06 |
| Reporter | weeks | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Nathan Weeks | ||||
| Organization | Iowa State University HPC Group | ||||
| User Reference | |||||
| Section | ftok | ||||
| Page Number | 958 | ||||
| Line Number | 32805 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | See 0000366:0000660 | ||||
| Summary | 0000366: ftok() with paths on the same filesystem | ||||
| Description | The ftok() description contains the text: The ftok() function shall ... return different key values when called with different id values or with paths that name different files existing on the same file system at the same time. At least the Solaris 10u9 and AIX 7.1 manual pages imply that different paths inthe same filesystem may result in the same key value. Also, the sentences describing the ftok() examples begin with "The following example gets a unique key...". | ||||
| Desired Action | Reword these parts if necessary. | ||||
| Tags | tc1-2008 | ||||
|
|
Just so the information will not be lost while considering the ways to resolve this: CDE [ http://www.opengroup.org/onlinepubs/9629399/toc.htm ] created a set of routines for creating unique identifiers (UUID) for use in interprocess communication, that may lead us to some answers for this problem. I know AIX and HP picked these up. |
|
|
For TC1, proposed change is: On line 32809 change "and return different key values when called with different id ..." to "and should return different key values when called with different id ..." Add to Application Usage: No guarantee can be given that the resulting key value is unique. In Examples, on line 32119 and 32129 delete the word "unique". In Future Directions change "None" to "Future versions of this standard may add new interfaces to provide guaranteed unique keys." |
|
|
Interpretation response ------------------------ The standard states that the key shall be unique, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- See notes above. No current implementation is known to provide unique keys. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- See 0000366:0000659 |
|
|
I think it is problematic that the interpretation even hints at a new interface to help solve the issue. The fundamental problem is that the key_t type is usually severely limited. Many implementations only use 16 bits. Not much uniqueness to achieve. Just as for IP ports (see the IETF proposals), the only way to get some uniqueness is to use strings. This we already have in the POSIX shm, msg, sem interfaces. If people are missing functionality in those interfaces, that's what would have to be worked on. Let the key_t-using interfaces die. Otherwise you'd have to implement a whole new set of interfaces and this will only create compatibility issues. |
|
|
Interpretation proposed 15 Mar 2011 for final 30 day review |
|
|
The interpretation is now approved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-12-29 02:51 | weeks | New Issue | |
| 2010-12-29 02:51 | weeks | Status | New => Under Review |
| 2010-12-29 02:51 | weeks | Assigned To | => ajosey |
| 2010-12-29 02:51 | weeks | Name | => Nathan Weeks |
| 2010-12-29 02:51 | weeks | Organization | => Iowa State University HPC Group |
| 2010-12-29 02:51 | weeks | Section | => ftok |
| 2010-12-29 02:51 | weeks | Page Number | => 0 |
| 2010-12-29 02:51 | weeks | Line Number | => 0 |
| 2011-01-20 17:53 | msbrown | Note Added: 0000654 | |
| 2011-01-27 17:07 | nick | Page Number | 0 => 958 |
| 2011-01-27 17:07 | nick | Line Number | 0 => 32805 |
| 2011-01-27 17:07 | nick | Interp Status | => --- |
| 2011-01-27 17:17 | nick | Note Added: 0000659 | |
| 2011-01-27 17:19 | nick | Interp Status | --- => Pending |
| 2011-01-27 17:19 | nick | Note Added: 0000660 | |
| 2011-01-27 17:19 | nick | Status | Under Review => Interpretation Required |
| 2011-01-27 17:19 | nick | Resolution | Open => Accepted As Marked |
| 2011-01-27 17:20 | nick | Final Accepted Text | => See 0000366:0000660 |
| 2011-01-27 17:20 | nick | Note Edited: 0000660 | |
| 2011-01-27 17:22 | nick | Tag Attached: tc1-2008 | |
| 2011-01-27 17:42 | drepper | Note Added: 0000662 | |
| 2011-03-15 14:46 | ajosey | Interp Status | Pending => Proposed |
| 2011-03-15 14:46 | ajosey | Note Added: 0000704 | |
| 2011-04-22 10:44 | eblake | Relationship added | related to 0000343 |
| 2011-04-26 15:11 | ajosey | Interp Status | Proposed => Approved |
| 2011-04-26 15:11 | ajosey | Note Added: 0000767 | |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
