[1003.1(2013)/Issue7+TC1 0000858]: highlight the dangers of using pthread_atfork()

[Austin Group Bug Tracker]

The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=858
======================================================================
Reported By: geoffclare
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 858
Category: System Interfaces
Type: Clarification Requested
Severity: Comment
Priority: normal
Status: New
Name: Geoff Clare
Organization: The Open Group
User Reference:
Section: pthread_atfork()
Page Number: 1543
Line Number: 50230,50244
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-07-11 14:31 UTC
Last Modified: 2014-07-11 14:31 UTC
======================================================================
Summary: highlight the dangers of using pthread_atfork()
Description:
A separate bug is needed for the changes proposed in
http://austingroupbugs.net/view.php?id=851#c2287
since these are suitable for TC2 but the changes to address
http://austingroupbugs.net/view.php?id=851 will
need to wait for Issue 8.

The aim here is make the warnings of the dangers of using pthread_atfork()
(which are currently buried in the RATIONALE) more prominent for the
benefit of application writers.

Desired Action:
After page 1543 line 50230 add a new paragraph:

If a <i>fork</i>() call in a multi-threaded process leads to a <i>child</i>
fork handler calling any function that is not async-signal-safe, the
behavior is undefined.

On page 1543 line 50244 change the APPLICATION USAGE section from:

None.

to:

The original usage pattern envisaged for <i>pthread_atfork</i>() was for
the <i>prepare</i> fork handler to lock mutexes and other locks, and for
the <i>parent</i> and <i>child</i> handlers to unlock them. However, since
all of the relevant unlocking functions, except <i>sem_post</i>(), are not
async-signal-safe this usage results in undefined behavior in the child
process unless the only such unlocking function it calls is
<i>sem_post</i>().

On page 1545 line 50308 change the FUTURE DIRECTIONS section from:

None.

to:

The <i>pthread_atfork</i>() function may be formally deprecated (for
example by shading it OB) in a future revision of this standard.

On page 889 line 29741 section fork() delete:

Fork handlers may be established by means of the <i>pthread_atfork</i>()
function in order to maintain application invariants across <i>fork</i>()
calls.

======================================================================

Issue History
Date Modified Username Field Change
======================================================================
2014-07-11 14:31 geoffclare New Issue
2014-07-11 14:31 geoffclare Name => Geoff Clare
2014-07-11 14:31 geoffclare Organization => The Open Group
2014-07-11 14:31 geoffclare Section => pthread_atfork()
2014-07-11 14:31 geoffclare Page Number => 1543
2014-07-11 14:31 geoffclare Line Number => 50230,50244
2014-07-11 14:31 geoffclare Interp Status => ---
======================================================================