Sun Microsystems, Inc. gratefully acknowledges The Open Group for
permission to reproduce portions of its copyrighted documentation.
Original documentation from The Open Group can be obtained online at
http://www.opengroup.org/bookstore/.
The Institute of Electrical and Electronics Engineers and The Open
Group, have given us permission to reprint portions of their
documentation.
In the following statement, the phrase ``this text'' refers to portions
of the system documentation.
Portions of this text are reprinted and reproduced in electronic form
in the SunOS Reference Manual, from IEEE Std 1003.1, 2004 Edition,
Standard for Information Technology -- Portable Operating System
Interface (POSIX), The Open Group Base Specifications Issue 6,
Copyright (C) 2001-2004 by the Institute of Electrical and Electronics
Engineers, Inc and The Open Group. In the event of any discrepancy
between these versions and the original IEEE and The Open Group
Standard, the original IEEE and The Open Group Standard is the referee
document. The original Standard can be obtained online at
http://www.opengroup.org/unix/online.html.
This notice shall appear on any product containing this material.
The contents of this file are subject to the terms of the
Common Development and Distribution License (the "License").
You may not use this file except in compliance with the License.
You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
or http://www.opensolaris.org/os/licensing.
See the License for the specific language governing permissions
and limitations under the License.
When distributing Covered Code, include this CDDL HEADER in each
file and include the License file at usr/src/OPENSOLARIS.LICENSE.
If applicable, add the following below this CDDL HEADER, with the
fields enclosed by brackets "[]" replaced with your own identifying
information: Portions Copyright [yyyy] [name of copyright owner]
Copyright 1991, 1992, 1994, The X/Open Company Ltd.
Copyright (c) 1995 IEEE. All Rights Reserved.
Copyright (c) 2001, The IEEE and The Open Group. All Rights Reserved.
Portions Copyright (c) 2008, Sun Microsystems, Inc. All Rights Reserved.
#include <sys/types.h> #include <unistd.h> int pthread_atfork(void (*prepare) (void), void (*parent) (void), void (*child) (void));
The pthread_atfork() function declares fork handlers to be called prior to and following fork(2), within the thread that called fork(). The order of calls to pthread_atfork() is significant.
Before fork() processing begins, the prepare fork handler is called. The prepare handler is not called if its address is NULL.
The parent fork handler is called after fork() processing finishes in the parent process, and the child fork handler is called after fork() processing finishes in the child process. If the address of parent or child is NULL, then its handler is not called.
The prepare fork handler is called in LIFO (last-in first-out) order, whereas the parent and child fork handlers are called in FIFO (first-in first-out) order. This calling order allows applications to preserve locking order.
Upon successful completion, pthread_atfork() returns 0. Otherwise, an error number is returned.
The pthread_atfork() function will fail if: ENOMEM
Insufficient table space exists to record the fork handler addresses.
Solaris threads do not offer pthread_atfork() functionality (there is no thr_atfork() interface). However, a Solaris threads application can call pthread_atfork() to ensure fork()-safety, since the two thread APIs are interoperable. See fork(2) for information relating to fork() in a Solaris threads environment in Solaris 10 relative to previous releases.
Example 1 Make a library safe with respect to fork().
All multithreaded applications that call fork() in a POSIX threads program and do more than simply call exec(2) in the child of the fork need to ensure that the child is protected from deadlock.
Since the "fork-one" model results in duplicating only the thread that called fork(), it is possible that at the time of the call another thread in the parent owns a lock. This thread is not duplicated in the child, so no thread will unlock this lock in the child. Deadlock occurs if the single thread in the child needs this lock.
The problem is more serious with locks in libraries. Since a library writer does not know if the application using the library calls fork(), the library must protect itself from such a deadlock scenario. If the application that links with this library calls fork() and does not call exec() in the child, and if it needs a library lock that may be held by some other thread in the parent that is inside the library at the time of the fork, the application deadlocks inside the library.
The following describes how to make a library safe with respect to fork() by using pthread_atfork().
1. Identify all locks used by the library (for example {L1,\|.\|.\|.Ln}). Identify also the locking order for these locks (for example {L1\|.\|.\|.Ln}, as well.)
2. Add a call to pthread_atfork(f1, f2, f3) in the library's .init section. f1, f2, f3 are defined as follows:
f1(\|)
{
/* ordered in lock order */
pthread_mutex_lock(L1);
pthread_mutex_lock(\|.\|.\|.);
pthread_mutex_lock(Ln);
}
f2(\|)
{
pthread_mutex_unlock(L1);
pthread_mutex_unlock(\|.\|.\|.);
pthread_mutex_unlock(Ln);
}
f3(\|)
{
pthread_mutex_unlock(L1);
pthread_mutex_unlock(\|.\|.\|.);
pthread_mutex_unlock(Ln);
}
See attributes(5) for descriptions of the following attributes:
| ATTRIBUTE TYPE ATTRIBUTE VALUE |
| Interface Stability Standard |
| MT-Level MT-Safe |
exec(2), fork(2), atexit(3C), attributes(5), standards(5)