Austin Group Defect Tracker

Aardvark Mark III


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 2013-05-03 12:18
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Interpretation Required  
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
related to 0000626Resolvedajosey Unclear whether fflush(0) and/or exit() affect memory streams 

-  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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker