A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=62
======================================================================
Reported By: msbrown
Assigned To: ajosey
======================================================================
Project: 1003.1(2008)/Issue 7
Issue ID: 62
Category: System Interfaces
Type: Clarification Requested
Severity: Comment
Priority: normal
Status: Under Review
Name: Mark Brown
Organization: IBM
User Reference:
Section: 2.4.3
Page Number: 489
Line Number: 16723
Final Accepted Text:
======================================================================
Date Submitted: 2009-06-26 14:02 MST
Last Modified: 2009-06-26 14:03 MST
======================================================================
Summary: 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?
======================================================================
----------------------------------------------------------------------
(0000121) msbrown (manager) - 2009-06-26 14:03
http://austingroupbugs.net/view.php?id=62#c121
----------------------------------------------------------------------
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]
|