 Relationships |
||||||
|
||||||
| Anonymous | Login | 2023-12-07 10:51 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 | ||
| 0000611 | [1003.1(2008)/Issue 7] System Interfaces | Editorial | Clarification Requested | 2012-09-24 21:11 | 2019-06-10 08:55 | ||
| 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 | exit | ||||||
| Page Number | unknown | ||||||
| Line Number | unknown | ||||||
| Interp Status | Approved | ||||||
| Final Accepted Text | Note: 0001395 | ||||||
| Summary | 0000611: Interaction of exit with stdio stream locking is not specified | ||||||
| Description |
The exit() function is specified to flush/close stdio streams: "The exit() function shall then flush all open streams with unwritten buffered data and close all open streams. Finally, the process shall be terminated with the same consequences as described in Consequences of Process Termination." However, no mention is made of what should happen if any streams are presently locked. The only possibly-relevant text I can find on this matter is in the specification of flockfile: "All functions that reference ( FILE *) objects shall behave as if they use flockfile() and funlockfile() internally to obtain ownership of these ( FILE *) objects." Does this mean exit should suspend the calling thread (possibly forever) waiting for a lock on each stream it needs to close? For example, a thread could have called flockfile on a stream and never unlocked it (to ensure it has permanent exclusive access) or could be blocked in a stdio read or write operation that will never complete, thereby holding the lock on the stream implicitly. At least some existing implementations are not blocked from exiting by other threads holding locks on stdio streams. |
||||||
| Desired Action |
I am not convinced there is any good solution that's compatible with existing practice, avoiding deadlock, and meeting application expectations. As such I have no recommendation for how the situation should be dealt with, except that the requirements (or lack of any requirements) placed on implementations should be clarified. |
||||||
| Tags | tc2-2008 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
||||||
|
||||||
|
Notes |
|
|
(0001388) Don Cragun (manager) 2012-10-03 16:13 edited on: 2012-10-03 16:15 |
There shouldn't be any unwritten data associated with any standard I/O handles in a conforming application. If you have unwritten buffered data in a stream that is not the current handle for that file, the results are undefined. See XSH section 2.5.1. |
|
(0001395) geoffclare (manager) 2012-10-10 15:48 edited on: 2012-10-10 15:51 |
Interpretation response ------------------------ The standard clearly states that all functions that reference (FILE *) objects (except those with names ending in _unlocked) shall behave as if they use flockfile() and funlockfile() internally to obtain ownership of these (FILE *) objects, and conforming implementations must conform to this. Rationale: ------------- The internal stream lock protects the data in the FILE structure. All functions, except those with names ending in _unlocked, which modify these data must obtain the stream lock before they do so, and that includes exit(). Notes to the Editor (not part of this interpretation): ------------------------------------------------------- After page 859 line 28523 section flockfile() add a new paragraph to APPLICATION USAGE: A call to exit() can block until locked streams are unlocked because a thread having ownership of a (FILE *) object blocks all function calls that reference that (FILE *) object (except those with names ending in _unlocked) from other threads, including calls to exit(). |
|
(0001523) ajosey (manager) 2013-03-29 08:05 |
Interpretation Proposed 29 Mar 2013 |
|
(0001572) ajosey (manager) 2013-05-03 12:18 |
Interpretation approved 3 May 2013 |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2012-09-24 21:11 | dalias | New Issue | |
| 2012-09-24 21:11 | dalias | Status | New => Under Review |
| 2012-09-24 21:11 | dalias | Assigned To | => ajosey |
| 2012-09-24 21:11 | dalias | Name | => Rich Felker |
| 2012-09-24 21:11 | dalias | Organization | => musl libc |
| 2012-09-24 21:11 | dalias | Section | => exit |
| 2012-09-24 21:11 | dalias | Page Number | => unknown |
| 2012-09-24 21:11 | dalias | Line Number | => unknown |
| 2012-10-03 16:13 | Don Cragun | Interp Status | => --- |
| 2012-10-03 16:13 | Don Cragun | Note Added: 0001388 | |
| 2012-10-03 16:13 | Don Cragun | Status | Under Review => Closed |
| 2012-10-03 16:13 | Don Cragun | Resolution | Open => Rejected |
| 2012-10-03 16:15 | Don Cragun | Note Edited: 0001388 | |
| 2012-10-10 15:48 | geoffclare | Note Added: 0001395 | |
| 2012-10-10 15:48 | geoffclare | Status | Closed => Under Review |
| 2012-10-10 15:48 | geoffclare | Resolution | Rejected => Reopened |
| 2012-10-10 15:49 | geoffclare | Interp Status | --- => Pending |
| 2012-10-10 15:49 | geoffclare | Final Accepted Text | => Note: 0001395 |
| 2012-10-10 15:49 | geoffclare | Status | Under Review => Interpretation Required |
| 2012-10-10 15:49 | geoffclare | Resolution | Reopened => Accepted As Marked |
| 2012-10-10 15:49 | geoffclare | Tag Attached: tc2-2008 | |
| 2012-10-10 15:51 | geoffclare | Note Edited: 0001395 | |
| 2012-11-07 16:41 | eblake | Relationship added | related to 0000626 |
| 2013-03-29 08:05 | ajosey | Interp Status | Pending => Proposed |
| 2013-03-29 08:05 | ajosey | Note Added: 0001523 | |
| 2013-05-03 12:18 | ajosey | Interp Status | Proposed => Approved |
| 2013-05-03 12:18 | ajosey | Note Added: 0001572 | |
| 2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
