View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00013171003.1(2016/18)/Issue7+TC2System Interfacespublic2020-01-11 12:402024-06-11 09:08
Reporternate_karstens Assigned To 
PrioritynormalSeverityCommentTypeEnhancement Request
Status ClosedResolutionAccepted As Marked 
NameNate Karstens
OrganizationGarmin
User Reference
Sectionsystem, popen, posix_spawn, etc.
Page NumberUnknown
Line NumberUnknown
Interp StatusApproved
Final Accepted TextSee 0001317:0004789
Summary0001317: Require fork handlers to be called in certain conditions
DescriptionNot defining whether fork handlers are called under certain scenarios can lead to undesired behavior and reduces the effectiveness of the pthread_atfork() interface.

Please see https://www.mail-archive.com/austin-group-l@opengroup.org/msg05324.html for a description of the issue and resulting discussion.
Desired ActionIn the definition of system(), change this:

It is unspecified whether the handlers registered with pthread_atfork() are called as part of the creation of the child process.

to this:

If the implementation of system() is non-atomic, then handlers registered with pthread_atfork() shall be called as part of the creation of the child process. If the implementation of system() is atomic , then it is unspecified whether the handlers registered with pthread_atfork() are called.

Add similar text to the definition of popen(), posix_spawn(), and any other interfaces that can fork/exec a child process without requiring the operation to be atomic.
Tagstc3-2008

Relationships

related to 0001318 Closed Define close-on-fork flag 

Activities

nick

2020-02-27 17:27

manager   bugnote:0004789

Last edited: 2020-02-27 17:37

 Interpretation response
------------------------
The standard states that popen() must call atfork handlers, and it is unspecified if system() call atfork handlers, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
Several existing implementations behave in different ways with respect to calling handlers, but this is important information for application developers.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

At page 2107, line 67569 - 67570 section system(), change:
It is unspecified whether the handlers registered with pthread_atfork( ) are called as part of the creation of the child process.
to:
It is implementation-defined whether the handlers registered with pthread_atfork( ) are called as part of the creation of the child process.

At page 1437 line 47731 section popen(), change:
where shell path is an unspecified pathname for the sh utility.
to:
where shell path is an unspecified pathname for the sh utility. It is implementation-defined whether the handlers registered with pthread_atfork( ) are called as part of the creation of the child process.

geoffclare

2020-02-27 17:38

manager   bugnote:0004790

Just to circumvent any replies of "that doesn't solve the problem" - those of us on the teleconference are aware of that. The change to system() is not being made to address the reported problem, it is just to make system() consistent with posix_spawn() in requiring implementations to document whether these functions call fork handlers. (The change to popen() is for consistency with the change to system() between Issue 6 and Issue 7.)

The original problem cannot be solved by any change related to whether fork handlers are called, because implementations have extensions which a third-party library could use to fork a process without fork handlers being called. Such a facility is also being standardised in Issue 8 (the _Fork() function).

ajosey

2020-04-30 15:25

manager   bugnote:0004834

Interpretation proposed: 30 April 2020

ajosey

2020-06-02 09:34

manager   bugnote:0004882

Approved: 2nd June 2020

Issue History

Date Modified Username Field Change
2020-01-11 12:40 nate_karstens New Issue
2020-01-11 12:40 nate_karstens Name => Nate Karstens
2020-01-11 12:40 nate_karstens Organization => Garmin
2020-01-11 12:40 nate_karstens Section => system, popen, posix_spawn, etc.
2020-01-11 12:40 nate_karstens Page Number => Unknown
2020-01-11 12:40 nate_karstens Line Number => Unknown
2020-02-27 17:27 nick Note Added: 0004789
2020-02-27 17:28 nick Note Edited: 0004789
2020-02-27 17:29 nick Note Edited: 0004789
2020-02-27 17:29 nick Tag Attached: issue8
2020-02-27 17:30 nick Interp Status => ---
2020-02-27 17:30 nick Final Accepted Text => See 0001317:0004789
2020-02-27 17:30 nick Status New => Resolved
2020-02-27 17:30 nick Resolution Open => Accepted As Marked
2020-02-27 17:32 nick Note Edited: 0004789
2020-02-27 17:37 nick Note Edited: 0004789
2020-02-27 17:37 nick Interp Status --- => Pending
2020-02-27 17:37 nick Status Resolved => Interpretation Required
2020-02-27 17:38 nick Tag Detached: issue8
2020-02-27 17:38 geoffclare Note Added: 0004790
2020-02-27 17:38 nick Tag Attached: tc3-2008
2020-03-05 17:30 eblake Relationship added related to 0001318
2020-04-30 15:25 ajosey Interp Status Pending => Proposed
2020-04-30 15:25 ajosey Note Added: 0004834
2020-06-02 09:34 ajosey Interp Status Proposed => Approved
2020-06-02 09:34 ajosey Note Added: 0004882
2020-06-17 14:01 geoffclare Status Interpretation Required => Applied
2024-06-11 09:08 agadmin Status Applied => Closed