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
0000062 [1003.1(2008)/Issue 7] System Interfaces Comment Clarification Requested 2009-06-26 14:02 2024-06-11 08:53
Reporter msbrown View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Mark Brown
Organization IBM
User Reference
Section 2.4.3
Page Number 489
Line Number 16723
Interp Status Approved
Final Accepted Text Note: 0000193
Summary 0000062: Is it correct to list fork as an async-signal safe interface
Description Section 2.4.3. P489 L16723 Asserts that fork() is async-signal safe.

 The fork() system interfaces section P882 L29311-29312 asserts that registered fork handlers are executed during the fork.

 P882 L 29313-29315 asserts that only async-signal safe functions are
 to be called by pthread_at_fork handlers to provide signal safety for fork().

 The rationale section of pthread_atfork() explains the purpose of
 these functions.

 As per this section, XSH P1529, L49389-49402, it is possible that
 multithreaded libraries could be used by single threaded
 applications. In which case, atfork handlers are essential for the
 libraries to protect their internal state during fork. As explained
 further P1530, L49403-49404, pthread_atfork functions are mainly
 required to acquire/release mutex locks, for protecting the
 applications/libraries from fork() calls. C-library needs to as well
 have an atfork handler which acquires all the required locks to
 protect its memory state across fork().


 The acquire/release mutex calls themselves are aync-signal unsafe
 operations. Use of them makes pthread_atfork handlers async-signal
 unsafe which in turn makes fork() async-signal unsafe when called by
 an application which is multi threaded, or which is linked to a
 library which is multi threaded.
Desired Action Need clarification with respect to
 1. Is it correct to list fork as an async-signal safe interface, in
 a multi threaded scenario?

 2. Can the implementation be allowed to not call the atfor handlers,
 when fork is called from a signal handler? If the atfork handlers
 are not going to be called when fork is called in the signal
 handler, then they can not be called, even if fork is called in the
 newly created child before exec.

 3. If only async-signal safe functions are to be called from
 pthread_atfork handlers, then how will multi-threaded librarie protect
 themselves by the fork calls, made by single threaded applications
 linked to them?
Tags issue8
Attached Files

- Relationships
related to 0000276Closed 1003.1(2008)/Issue 7 declare vfork as async signal safe 
has duplicate 0000018Closed 1003.1(2008)/Issue 7 _Fork() is needed to allow execution of the fork operation from a signal handler 
related to 0001361Closed Issue 8 drafts fork() changes incomplete 
related to 0001112Closed 1003.1(2016/18)/Issue7+TC2 mutex/rwlock ownership after fork is unclear 

-  Notes
(0000121)
msbrown (manager)
2009-06-26 14:03

 We agreed not to send this down the interps track yet.

The standard is clear and concerns are being forwarded to the sponsor.
A previous interpretation 1003.1c-1995 #37, and also ERN XSHbug2145 have
addressed the same issue, but still the problem has remained unresolved.

Because of the problems which exist here it has become
clear that an application using pthread_atfork(), even if the application itself
did not call pthread_atfork(), may have had pthread_atfork() handlers
installed by a third party library or the implementation. Therefore
calling fork() from an asynchronous signal handler is undefined.
Therefore we are removing fork() from the list of
async-signal-safe functions.


Recommendations for a future revision:
A future revision should mandate posix_spawn() and add that to the list
of async-signal-safe functions.
Remove fork() from the list of async-signal-safe functions.
[ 12 Feb 2009 - we had no consensus on the changes for a future revision]
(0000122)
msbrown (manager)
2009-06-26 14:06

 Original Report:
 COMMENT Enhancement Request Number 15
 rajani.g.k:xxxxxx Defect in XSH 2.4.3 (rdvk# 6)
 {GKRFORK012009} Thu, 8 Jan 2009 07:41:10 GMT
(0000193)
ajosey (manager)
2009-08-13 15:33
edited on: 2011-12-06 16:20

 Interpretation response
------------------------
The standard states the requirements for fork() and async-signal safety,
and conforming implementations must conform to this. However, concerns
have been raised about this which are being referred to the sponsor."

Rationale:
-------------
None.

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

Add to the end of fork() DESCRIPTION:
The _Fork() function shall be equivalent to fork(), except that fork handlers
established by means of the pthread_atfork() function shall not be called and
_Fork() shall be async-signal-safe.

Add to SYNOPSIS on fork() page: pid_t _Fork(void);
and also to unistd.h

Add _Fork() to the list of async-signal-safe functions
Remove fork() from the list of async-signal-safe functions.
(0000455)
fahree (reporter)
2010-07-02 15:21

 Isn't it what vfork was created for?

fork should execute the atfork handlers, and vfork shouldn't. Problem solved. vfork can remain async signal safe and be used to implement posix_spawn or whatelse.
(0000527)
geoffclare (manager)
2010-08-19 15:38
edited on: 2010-08-19 15:42

 The vfork() function had heavy restrictions on the child process.
Quoting SUSv3:

   the behavior is undefined if the process created by vfork() either
   modifies any data other than a variable of type pid_t used to store
   the return value from vfork(), or returns from the function in
   which vfork() was called, or calls any other function before
   successfully calling _exit() or one of the exec family of
   functions.

Therefore it is not a suitable solution to the issue of fork()
async-signal-safety.
(0001399)
dalias (reporter)
2012-10-15 15:59

 In regards to the future direction of making posix_spawn async-signal-safe, this change would have limited utility since the functions to build file actions operate in a way that is not feasible to make async-signal-safe; many/most real-world usages of posix_spawn need to customize the file actions just before calling posix_spawn based on newly-opened files intended for use in the spawned program.

Ideally, there would be a function like posix_spawn but which takes a pointer to an array of pointers to non-opaque spawn-action structures. This design would facilitate extensibility of the spawn-action structure (using an array of pointers rather than an array of structures) and it could be constructed in an async-signal-safe manner at spawn time. It would also make it easier for implementations to add custom actions (such as changing resource limits, supplemental groups, etc.) simply by defining new macros for use in the spawn action structure, instead of requiring new functions to be added.
(0001400)
geoffclare (manager)
2012-10-15 16:20

 (Response to Note: 0001399).
There is no agreement to make posix_spawn() async-signal-safe.
Presumably you are looking at Note: 0000121. This was superseded
by Note: 0000193. To tell which bugnote has the official response,
you need to look at the "Final Accepted Text" field.
(0001402)
dalias (reporter)
2012-10-15 16:29

 Thanks for the tips. I saw that it was not a formal decision, just a recommendation for something to be considered in the future, and added the note so there's some record of why making posix_spawn async-signal-safe would fail to meet many applications' needs and what would be needed for a useful async-signal-safe interface analogous to posix_spawn.

- Issue History
Date Modified Username Field Change
2009-06-26 14:02 msbrown New Issue
2009-06-26 14:02 msbrown Status New => Under Review
2009-06-26 14:02 msbrown Assigned To => ajosey
2009-06-26 14:02 msbrown Name => Mark Brown
2009-06-26 14:02 msbrown Organization => IBM
2009-06-26 14:02 msbrown Section => 2.4.3
2009-06-26 14:02 msbrown Page Number => 489
2009-06-26 14:02 msbrown Line Number => 16723
2009-06-26 14:03 msbrown Note Added: 0000121
2009-06-26 14:06 msbrown Note Added: 0000122
2009-06-26 14:08 msbrown Relationship added has duplicate 0000018
2009-08-13 15:33 ajosey Interp Status => Pending
2009-08-13 15:33 ajosey Note Added: 0000193
2009-08-13 15:33 ajosey Status Under Review => Interpretation Required
2009-08-13 15:35 ajosey Final Accepted Text => Note: 0000193
2009-08-13 15:35 ajosey Resolution Open => Accepted As Marked
2009-09-17 06:51 tahonermann Issue Monitored: tahonermann
2009-09-17 15:41 nick Interp Status Pending => Proposed
2009-10-09 16:21 ajosey Note Edited: 0000193
2009-10-09 16:22 ajosey Interp Status Proposed => Approved
2010-07-02 15:21 fahree Note Added: 0000455
2010-08-12 21:45 ldwyer Issue Monitored: ldwyer
2010-08-19 15:38 geoffclare Note Added: 0000527
2010-08-19 15:41 nick Relationship added related to 0000276
2010-08-19 15:42 geoffclare Note Edited: 0000527
2010-09-20 09:09 geoffclare Tag Attached: issue8
2011-12-06 16:20 geoffclare Note Edited: 0000193
2012-10-15 15:59 dalias Note Added: 0001399
2012-10-15 16:20 geoffclare Note Added: 0001400
2012-10-15 16:29 dalias Note Added: 0001402
2015-04-23 23:02 emaste Issue Monitored: emaste
2019-12-17 15:52 geoffclare Status Interpretation Required => Applied
2020-07-02 13:53 geoffclare Relationship added related to 0001361
2023-02-23 15:36 eblake Relationship added related to 0001112
2024-06-11 08:53 agadmin Status Applied => Closed

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