The following issue has been SUBMITTED.
======================================================================
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:02 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?
======================================================================
|