1PTHREAD_ATFORK(3P) POSIX Programmer's Manual PTHREAD_ATFORK(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 pthread_atfork - register fork handlers
13
15 #include <pthread.h>
16 int pthread_atfork(void (*prepare)(void), void (*parent)(void),
18 void (*child)(void));
19
22 The pthread_atfork() function shall declare fork handlers to be called
23 before and after fork(), in the context of the thread that called
24 fork(). The prepare fork handler shall be called before fork() process‐
25 ing commences. The parent fork handle shall be called after fork() pro‐
26 cessing completes in the parent process. The child fork handler shall
27 be called after fork() processing completes in the child process. If
28 no handling is desired at one or more of these three points, the corre‐
29 sponding fork handler address(es) may be set to NULL.
30 The order of calls to pthread_atfork() is significant. The parent and
32 child fork handlers shall be called in the order in which they were
33 established by calls to pthread_atfork(). The prepare fork handlers
34 shall be called in the opposite order.
35
37 Upon successful completion, pthread_atfork() shall return a value of
38 zero; otherwise, an error number shall be returned to indicate the
39 error.
40
42 The pthread_atfork() function shall fail if:
43 ENOMEM Insufficient table space exists to record the fork handler
45 addresses.
46 The pthread_atfork() function shall not return an error code of
49 [EINTR].
50 The following sections are informative.
52
54 None.
55
57 None.
58
60 There are at least two serious problems with the semantics of fork() in
61 a multi-threaded program. One problem has to do with state (for exam‐
62 ple, memory) covered by mutexes. Consider the case where one thread has
63 a mutex locked and the state covered by that mutex is inconsistent
64 while another thread calls fork(). In the child, the mutex is in the
65 locked state (locked by a nonexistent thread and thus can never be
66 unlocked). Having the child simply reinitialize the mutex is unsatis‐
67 factory since this approach does not resolve the question about how to
68 correct or otherwise deal with the inconsistent state in the child.
69 It is suggested that programs that use fork() call an exec function
71 very soon afterwards in the child process, thus resetting all states.
72 In the meantime, only a short list of async-signal-safe library rou‐
73 tines are promised to be available.
74 Unfortunately, this solution does not address the needs of multi-
76 threaded libraries. Application programs may not be aware that a multi-
77 threaded library is in use, and they feel free to call any number of
78 library routines between the fork() and exec calls, just as they always
79 have. Indeed, they may be extant single-threaded programs and cannot,
80 therefore, be expected to obey new restrictions imposed by the threads
81 library.
82 On the other hand, the multi-threaded library needs a way to protect
84 its internal state during fork() in case it is re-entered later in the
85 child process. The problem arises especially in multi-threaded I/O
86 libraries, which are almost sure to be invoked between the fork() and
87 exec calls to effect I/O redirection. The solution may require locking
88 mutex variables during fork(), or it may entail simply resetting the
89 state in the child after the fork() processing completes.
90 The pthread_atfork() function provides multi-threaded libraries with a
92 means to protect themselves from innocent application programs that
93 call fork(), and it provides multi-threaded application programs with a
94 standard mechanism for protecting themselves from fork() calls in a
95 library routine or the application itself.
96 The expected usage is that the prepare handler acquires all mutex locks
98 and the other two fork handlers release them.
99 For example, an application can supply a prepare routine that acquires
101 the necessary mutexes the library maintains and supply child and parent
102 routines that release those mutexes, thus ensuring that the child gets
103 a consistent snapshot of the state of the library (and that no mutexes
104 are left stranded). Alternatively, some libraries might be able to
105 supply just a child routine that reinitializes the mutexes in the
106 library and all associated states to some known value (for example,
107 what it was when the image was originally executed).
108 When fork() is called, only the calling thread is duplicated in the
110 child process. Synchronization variables remain in the same state in
111 the child as they were in the parent at the time fork() was called.
112 Thus, for example, mutex locks may be held by threads that no longer
113 exist in the child process, and any associated states may be inconsis‐
114 tent. The parent process may avoid this by explicit code that acquires
115 and releases locks critical to the child via pthread_atfork(). In
116 addition, any critical threads need to be recreated and reinitialized
117 to the proper state in the child (also via pthread_atfork()).
118 A higher-level package may acquire locks on its own data structures
120 before invoking lower-level packages. Under this scenario, the order
121 specified for fork handler calls allows a simple rule of initialization
122 for avoiding package deadlock: a package initializes all packages on
123 which it depends before it calls the pthread_atfork() function for
124 itself.
125
127 None.
128
130 atexit(), fork(), the Base Definitions volume of IEEE Std 1003.1-2001,
131 <sys/types.h>
132
134 Portions of this text are reprinted and reproduced in electronic form
135 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
136 -- Portable Operating System Interface (POSIX), The Open Group Base
137 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
138 Electrical and Electronics Engineers, Inc and The Open Group. In the
139 event of any discrepancy between this version and the original IEEE and
140 The Open Group Standard, the original IEEE and The Open Group Standard
141 is the referee document. The original Standard can be obtained online
142 at http://www.opengroup.org/unix/online.html .
143IEEE/The Open Group 2003 PTHREAD_ATFORK(3P)