Austin Group Defect Tracker

Aardvark Mark III

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 2009-10-09 16:22
Reporter msbrown View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Interpretation Required  
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 No tags attached.
Attached Files

- Relationships
has duplicate 0000018Closed _Fork() is needed to allow execution of the fork operation from a signal handler 

-  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: 2009-10-09 16:21

 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.

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.

- 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

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