Anonymous | Login | 2024-11-12 19:55 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0000689 | [1003.1(2008)/Issue 7] System Interfaces | Editorial | Clarification Requested | 2013-05-05 15:37 | 2024-06-11 08:52 | ||
Reporter | dalias | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Rich Felker | ||||||
Organization | musl libc | ||||||
User Reference | |||||||
Section | XSH 2.5 | ||||||
Page Number | unknown | ||||||
Line Number | unknown | ||||||
Interp Status | Approved | ||||||
Final Accepted Text | Note: 0006428 | ||||||
Summary | 0000689: Possibly unintended allowance for stdio deadlock | ||||||
Description |
XSH 2.5 paragraph 2 reads: "When a stream is "unbuffered", bytes are intended to appear from the source or at the destination as soon as possible; otherwise, bytes may be accumulated and transmitted as a block. When a stream is "fully buffered", bytes are intended to be transmitted as a block when a buffer is filled. When a stream is "line buffered", bytes are intended to be transmitted as a block when a <newline> byte is encountered. Furthermore, bytes are intended to be transmitted as a block when a buffer is filled, when input is requested on an unbuffered stream, or when input is requested on a line-buffered stream that requires the transmission of bytes. Support for these characteristics is implementation-defined, and may be affected via setbuf() and setvbuf()." This intent, albeit implementation-defined and thus not in itself normative, reflects the traditional practice of having stdio input functions flush line-buffered streams, to accommodate lazy programming practices such as: printf("Prompt: "); scanf("%d", &x); with no intervening fflush. Unfortunately, encouraging or even permitting reads to flush all line-buffered output streams has some heavy locking consequences for multithreaded programs, including the possibility of deadlock. If thread A is holding a lock on a line-buffered output stream while waiting for a result from thread B, and thread B happens to use stdio for reading any file as part of its operation (unrelated to thread A's use of the line-buffered stream), the program will deadlock. This behavior seems highly undesirable and unintended. |
||||||
Desired Action |
My understanding is that a definition of "multithreaded program" is being added to the standard, with the intent that certain legacy implementation practices (like the alarm-based sleep implementation) that are incompatible or problematic for multithreaded programs can be ruled out for multithreaded programs while still allowing them in singlethreaded programs. If so, I think it would make sense to make use of that here, by adding text along the lines of: "In a multithreaded program, performing an operation on a stream shall not cause any other open stream to be locked as if by flockfile. In particular, performing an input operation which results in bytes being transferred shall not cause line-buffered streams to be flushed in a multithreaded program." |
||||||
Tags | applied_after_i8d3, issue8 | ||||||
Attached Files | |||||||
|
Issue History | |||
Date Modified | Username | Field | Change |
2013-05-05 15:37 | dalias | New Issue | |
2013-05-05 15:37 | dalias | Status | New => Under Review |
2013-05-05 15:37 | dalias | Assigned To | => ajosey |
2013-05-05 15:37 | dalias | Name | => Rich Felker |
2013-05-05 15:37 | dalias | Organization | => musl libc |
2013-05-05 15:37 | dalias | Section | => XSH 2.5 |
2013-05-05 15:37 | dalias | Page Number | => unknown |
2013-05-05 15:37 | dalias | Line Number | => unknown |
2013-05-05 17:13 | jilles | Note Added: 0001588 | |
2013-05-05 18:11 | dalias | Note Added: 0001589 | |
2013-05-07 11:08 | geoffclare | Note Added: 0001591 | |
2015-05-07 08:34 | dancol | Issue Monitored: dancol | |
2023-08-10 16:29 | geoffclare | Note Added: 0006428 | |
2023-08-10 16:31 | geoffclare | Interp Status | => Pending |
2023-08-10 16:31 | geoffclare | Final Accepted Text | => Note: 0006428 |
2023-08-10 16:31 | geoffclare | Status | Under Review => Interpretation Required |
2023-08-10 16:31 | geoffclare | Resolution | Open => Accepted As Marked |
2023-08-10 16:31 | geoffclare | Tag Attached: issue8 | |
2023-08-14 16:07 | agadmin | Interp Status | Pending => Proposed |
2023-08-14 16:07 | agadmin | Note Added: 0006432 | |
2023-10-02 14:30 | agadmin | Interp Status | Proposed => Approved |
2023-10-02 14:30 | agadmin | Note Added: 0006504 | |
2023-10-10 09:13 | geoffclare | Status | Interpretation Required => Applied |
2023-10-10 09:13 | geoffclare | Tag Attached: applied_after_i8d3 | |
2024-06-11 08:52 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |