Viewing Issue Simple Details
[ Jump to Notes ]
|
[ Issue History ]
[ Print ]
|
ID |
Category |
Severity |
Type |
Date Submitted |
Last Update |
0000904 |
[1003.1(2013)/Issue7+TC1] Rationale |
Editorial |
Error |
2014-12-12 16:24 |
2019-06-10 08:54 |
|
Reporter |
nick |
View Status |
public |
|
Assigned To |
|
Priority |
normal |
Resolution |
Accepted As Marked |
|
Status |
Closed |
|
|
|
|
Name |
Nick Stoughton |
Organization |
USENIX |
User Reference |
nms-threadsafe-rationale |
Section |
B.2.9.1 Thread-Safety |
Page Number |
3606 |
Line Number |
122868 |
Interp Status |
--- |
Final Accepted Text |
Note: 0002520 |
|
Summary |
0000904: Rationale uses non-existant limit {PIPE_MAX} |
Description |
The first sentence of the second paragraph reads
While a read from a pipe of {PIPE_MAX}*2 bytes may not generate a single atomic and thread-safe stream of bytes, it should generate ‘‘several’’ (individually atomic) thread-safe streams of bytes.
However, a search for "PIPE_MAX" throughout the standard finds only one other (non-index) mention of PIPE_MAX, in the rationale for write():
The concept of a {PIPE_MAX} limit (indicating the maximum number of bytes that can be written to a pipe in a single operation) was considered, but rejected, because this concept would unnecessarily limit application writing.
These two conflicting pieces of rationale should be aligned. |
Desired Action |
On page 3606, line 122868, change
While a read from a pipe of {PIPE_MAX}*2 bytes may not generate a single atomic ...
To
While a read from a pipe may not generate a single atomic ...
|
Tags |
tc2-2008 |
|
Attached Files |
|
|