1PTHREAD_ATFORK(P)          POSIX Programmer's Manual         PTHREAD_ATFORK(P)
2
3
4

NAME

6       pthread_atfork - register fork handlers
7

SYNOPSIS

9       #include <pthread.h>
10
11       int pthread_atfork(void (*prepare)(void), void (*parent)(void),
12              void (*child)(void));
13
14

DESCRIPTION

16       The  pthread_atfork() function shall declare fork handlers to be called
17       before and after fork(), in the  context  of  the  thread  that  called
18       fork(). The prepare fork handler shall be called before fork() process‐
19       ing commences. The parent fork handle shall be called after fork() pro‐
20       cessing  completes  in the parent process. The child fork handler shall
21       be called after fork() processing completes in the child  process.   If
22       no handling is desired at one or more of these three points, the corre‐
23       sponding fork handler address(es) may be set to NULL.
24
25       The order of calls to pthread_atfork() is significant. The  parent  and
26       child  fork  handlers  shall  be called in the order in which they were
27       established by calls to pthread_atfork().  The  prepare  fork  handlers
28       shall be called in the opposite order.
29

RETURN VALUE

31       Upon  successful  completion,  pthread_atfork() shall return a value of
32       zero; otherwise, an error number shall  be  returned  to  indicate  the
33       error.
34

ERRORS

36       The pthread_atfork() function shall fail if:
37
38       ENOMEM Insufficient  table  space  exists  to  record  the fork handler
39              addresses.
40
41
42       The pthread_atfork()  function  shall  not  return  an  error  code  of
43       [EINTR].
44
45       The following sections are informative.
46

EXAMPLES

48       None.
49

APPLICATION USAGE

51       None.
52

RATIONALE

54       There are at least two serious problems with the semantics of fork() in
55       a multi-threaded program. One problem has to do with state  (for  exam‐
56       ple, memory) covered by mutexes. Consider the case where one thread has
57       a mutex locked and the state covered  by  that  mutex  is  inconsistent
58       while  another  thread  calls fork(). In the child, the mutex is in the
59       locked state (locked by a nonexistent thread  and  thus  can  never  be
60       unlocked).  Having  the child simply reinitialize the mutex is unsatis‐
61       factory since this approach does not resolve the question about how  to
62       correct or otherwise deal with the inconsistent state in the child.
63
64       It  is  suggested  that  programs that use fork() call an exec function
65       very soon afterwards in the child process, thus resetting  all  states.
66       In  the  meantime,  only a short list of async-signal-safe library rou‐
67       tines are promised to be available.
68
69       Unfortunately, this solution does  not  address  the  needs  of  multi-
70       threaded libraries. Application programs may not be aware that a multi-
71       threaded library is in use, and they feel free to call  any  number  of
72       library routines between the fork() and exec calls, just as they always
73       have.  Indeed, they may be extant single-threaded programs and  cannot,
74       therefore,  be expected to obey new restrictions imposed by the threads
75       library.
76
77       On the other hand, the multi-threaded library needs a  way  to  protect
78       its  internal state during fork() in case it is re-entered later in the
79       child process. The problem  arises  especially  in  multi-threaded  I/O
80       libraries,  which  are almost sure to be invoked between the fork() and
81       exec calls to effect I/O redirection. The solution may require  locking
82       mutex  variables  during  fork(), or it may entail simply resetting the
83       state in the child after the fork() processing completes.
84
85       The pthread_atfork() function provides multi-threaded libraries with  a
86       means  to  protect  themselves  from innocent application programs that
87       call fork(), and it provides multi-threaded application programs with a
88       standard  mechanism  for  protecting  themselves from fork() calls in a
89       library routine or the application itself.
90
91       The expected usage is that the prepare handler acquires all mutex locks
92       and the other two fork handlers release them.
93
94       For  example, an application can supply a prepare routine that acquires
95       the necessary mutexes the library maintains and supply child and parent
96       routines  that release those mutexes, thus ensuring that the child gets
97       a consistent snapshot of the state of the library (and that no  mutexes
98       are  left  stranded).   Alternatively,  some libraries might be able to
99       supply just a child routine  that  reinitializes  the  mutexes  in  the
100       library  and  all  associated  states to some known value (for example,
101       what it was when the image was originally executed).
102
103       When fork() is called, only the calling thread  is  duplicated  in  the
104       child  process.   Synchronization variables remain in the same state in
105       the child as they were in the parent at the  time  fork()  was  called.
106       Thus,  for  example,  mutex locks may be held by threads that no longer
107       exist in the child process, and any associated states may be  inconsis‐
108       tent.  The parent process may avoid this by explicit code that acquires
109       and releases locks critical to  the  child  via  pthread_atfork().   In
110       addition,  any  critical threads need to be recreated and reinitialized
111       to the proper state in the child (also via pthread_atfork()).
112
113       A higher-level package may acquire locks on  its  own  data  structures
114       before  invoking  lower-level  packages. Under this scenario, the order
115       specified for fork handler calls allows a simple rule of initialization
116       for  avoiding  package  deadlock: a package initializes all packages on
117       which it depends before it  calls  the  pthread_atfork()  function  for
118       itself.
119

FUTURE DIRECTIONS

121       None.
122

SEE ALSO

124       atexit()    ,    fork()    ,    the    Base   Definitions   volume   of
125       IEEE Std 1003.1-2001, <sys/types.h>
126
128       Portions of this text are reprinted and reproduced in  electronic  form
129       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
130       -- Portable Operating System Interface (POSIX),  The  Open  Group  Base
131       Specifications  Issue  6,  Copyright  (C) 2001-2003 by the Institute of
132       Electrical and Electronics Engineers, Inc and The Open  Group.  In  the
133       event of any discrepancy between this version and the original IEEE and
134       The Open Group Standard, the original IEEE and The Open Group  Standard
135       is  the  referee document. The original Standard can be obtained online
136       at http://www.opengroup.org/unix/online.html .
137
138
139
140IEEE/The Open Group                  2003                    PTHREAD_ATFORK(P)
Impressum