View Issue Details

IDProjectCategoryView StatusLast Update
00000621003.1(2008)/Issue 7System Interfacespublic2024-06-11 08:53
Reportermsbrown Assigned Toajosey  
PrioritynormalSeverityCommentTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
NameMark Brown
OrganizationIBM
User Reference
Section2.4.3
Page Number489
Line Number16723
Interp StatusApproved
Final Accepted Text0000062:0000193
Summary0000062: Is it correct to list fork as an async-signal safe interface
DescriptionSection 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 ActionNeed 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?
Tagsissue8

Relationships

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

Activities

msbrown

2009-06-26 14:03

manager   bugnote:0000121

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]

msbrown

2009-06-26 14:06

manager   bugnote:0000122

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

ajosey

2009-08-13 15:33

manager   bugnote:0000193

Last edited: 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.

fahree

2010-07-02 15:21

reporter   bugnote:0000455

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.

geoffclare

2010-08-19 15:38

manager   bugnote:0000527

Last edited: 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.

dalias

2012-10-15 15:59

reporter   bugnote:0001399

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.

geoffclare

2012-10-15 16:20

manager   bugnote:0001400

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

dalias

2012-10-15 16:29

reporter   bugnote:0001402

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 => 0000062:0000193
2009-08-13 15:35 ajosey Resolution Open => Accepted As Marked
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-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
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