See https://bugzilla.kernel.org/show_bug.cgi?id=25292
And there will likely be future changes as well.
Quoting http://www.opengroup.org/austin/aardvark/latest/xshbug3.txt:
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
[...]
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.
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?
Reported-by: KASAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Also:
* add more detail on changes across standards
* provide proper section cross references in function references
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk