|
Viewing Issue Simple Details
[ Jump to Notes ]
|
[ Issue History ]
[ Print ]
|
|
ID |
Category |
Severity |
Type |
Date Submitted |
Last Update |
|
0000695 |
[1003.1(2008)/Issue 7] System Interfaces |
Editorial |
Clarification Requested |
2013-05-12 04:08 |
2013-05-12 04:08 |
|
|
Reporter |
dalias |
View Status |
public |
|
|
Assigned To |
ajosey |
|
Priority |
normal |
Resolution |
Open |
|
|
Status |
Under Review |
|
|
|
|
|
Name |
Rich Felker |
|
Organization |
musl libc |
|
User Reference |
|
|
Section |
XSH 2.9.7 Thread Interactions with Regular File Operations |
|
Page Number |
unknown |
|
Line Number |
unknown |
|
Interp Status |
--- |
|
Final Accepted Text |
|
|
|
Summary |
0000695: Missing/lax atomicity requirements for file operations |
|
Description |
XSH 2.9.7 guarantees atomicity of most operations on file descriptors, but only when they refer to regular files. I suspect the main situation in which it was desired to leave atomicity unspecified was for actual input and output on non-regular files. However, this leaves ambiguous several potentially-important cases such as:
- Atomicity of ftruncate on shared memory objects.
- Atomicity of dup2 and fcntl F_DUPFD[_CLOEXEC].
- Atomicity of F_SETOWN on sockets.
- Atomicity of ownership/permissions changes on non-regular files.
|
|
Desired Action |
Provide a reasonable degree of atomicity requirements for file operations consistent with present real-world implementations, preferably enumerating the non-atomic cases rather than the atomic ones.
Document that, even in the case where file operations are not atomic, concurrent access does not result in undefined behavior, but may result in data interleaving (and possibly data loss if it's deemed important to leave that possibility open as well).
|
| Tags |
No tags attached. |
|
|
Attached Files |
|
|
|
Relationships 
