Austin Group Defect Tracker

Aardvark Mark IV

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
0001317 [1003.1(2016/18)/Issue7+TC2] System Interfaces Comment Enhancement Request 2020-01-11 12:40 2024-06-11 09:08
Reporter nate_karstens View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Nate Karstens
Organization Garmin
User Reference
Section system, popen, posix_spawn, etc.
Page Number Unknown
Line Number Unknown
Interp Status Approved
Final Accepted Text See Note: 0004789
Summary 0001317: Require fork handlers to be called in certain conditions
Description Not 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 Action In 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.
Tags tc3-2008
Attached Files

- Relationships
related to 0001318Closed Define close-on-fork flag 

-  Notes
(0004789)
nick (manager)
2020-02-27 17:27
edited on: 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.
(0004790)
geoffclare (manager)
2020-02-27 17:38

 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).
(0004834)
ajosey (manager)
2020-04-30 15:25

 Interpretation proposed: 30 April 2020
(0004882)
ajosey (manager)
2020-06-02 09:34

 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 Note: 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

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