# pthread_atfork

## PROLOG



           This manual page is part of the POSIX Programmer's Manual.  The
           Linux implementation of this interface may differ (consult the
           corresponding Linux manual page for details of Linux behavior), or
           the interface may not be implemented on Linux.
    


## NAME



           pthread_atfork — register fork handlers
    


## SYNOPSIS



           #include <pthread.h>
    
           int pthread_atfork(void (*_prepare_)(void), void (*_parent_)(void),
               void (*_child_)(void));
    


## DESCRIPTION



           The _pthread_atfork_() function shall declare fork handlers to be
           called before and after _fork_(), in the context of the thread that
           called _fork_().  The _prepare_ fork handler shall be called before
           _fork_() processing commences. The _parent_ fork handle shall be
           called after _fork_() processing completes in the parent process.
           The _child_ fork handler shall be called after _fork_() processing
           completes in the child process. If no handling is desired at one
           or more of these three points, the corresponding fork handler
           address(es) may be set to NULL.
    
           If a _fork_() call in a multi-threaded process leads to a _child_ fork
           handler calling any function that is not async-signal-safe, the
           behavior is undefined.
    
           The order of calls to _pthread_atfork_() is significant. The _parent_
           and _child_ fork handlers shall be called in the order in which they
           were established by calls to _pthread_atfork_().  The _prepare_ fork
           handlers shall be called in the opposite order.
    


## RETURN VALUE



           Upon successful completion, _pthread_atfork_() shall return a value
           of zero; otherwise, an error number shall be returned to indicate
           the error.
    


## ERRORS



           The _pthread_atfork_() function shall fail if:
    
           **ENOMEM** Insufficient table space exists to record the fork handler
                  addresses.
    
           The _pthread_atfork_() function shall not return an error code of
           **[EINTR]**.
    
           _The following sections are informative._
    


## EXAMPLES



           None.
    


## APPLICATION USAGE



           The original usage pattern envisaged for _pthread_atfork_() was for
           the _prepare_ fork handler to lock mutexes and other locks, and for
           the _parent_ and _child_ handlers to unlock them. However, since all
           of the relevant unlocking functions, except _sem_post_(), are not
           async-signal-safe, this usage results in undefined behavior in the
           child process unless the only such unlocking function it calls is
           _sem_post_().
    


## RATIONALE



           There are at least two serious problems with the semantics of
           _fork_() in a multi-threaded program. One problem has to do with
           state (for example, memory) covered by mutexes. Consider the case
           where one thread has a mutex locked and the state covered by that
           mutex is inconsistent while another thread calls _fork_().  In the
           child, the mutex is in the locked state (locked by a nonexistent
           thread and thus can never be unlocked). Having the child simply
           reinitialize the mutex is unsatisfactory since this approach does
           not resolve the question about how to correct or otherwise deal
           with the inconsistent state in the child.
    
           It is suggested that programs that use _fork_() call an _exec_
           function very soon afterwards in the child process, thus resetting
           all states. In the meantime, only a short list of async-signal-
           safe library routines are promised to be available.
    
           Unfortunately, this solution does not address the needs of multi-
           threaded libraries. Application programs may not be aware that a
           multi-threaded library is in use, and they feel free to call any
           number of library routines between the _fork_() and _exec_ calls, just
           as they always have. Indeed, they may be extant single-threaded
           programs and cannot, therefore, be expected to obey new
           restrictions imposed by the threads library.
    
           On the other hand, the multi-threaded library needs a way to
           protect its internal state during _fork_() in case it is re-entered
           later in the child process. The problem arises especially in
           multi-threaded I/O libraries, which are almost sure to be invoked
           between the _fork_() and _exec_ calls to effect I/O redirection. The
           solution may require locking mutex variables during _fork_(), or it
           may entail simply resetting the state in the child after the
           _fork_() processing completes.
    
           The _pthread_atfork_() function was intended to provide multi-
           threaded libraries with a means to protect themselves from
           innocent application programs that call _fork_(), and to provide
           multi-threaded application programs with a standard mechanism for
           protecting themselves from _fork_() calls in a library routine or
           the application itself.
    
           The expected usage was that the prepare handler would acquire all
           mutex locks and the other two fork handlers would release them.
    
           For example, an application could have supplied a prepare routine
           that acquires the necessary mutexes the library maintains and
           supplied child and parent routines that release those mutexes,
           thus ensuring that the child would have got a consistent snapshot
           of the state of the library (and that no mutexes would have been
           left stranded). This is good in theory, but in reality not
           practical. Each and every mutex and lock in the process must be
           located and locked. Every component of a program including third-
           party components must participate and they must agree who is
           responsible for which mutex or lock. This is especially
           problematic for mutexes and locks in dynamically allocated memory.
           All mutexes and locks internal to the implementation must be
           locked, too. This possibly delays the thread calling _fork_() for a
           long time or even indefinitely since uses of these synchronization
           objects may not be under control of the application. A final
           problem to mention here is the problem of locking streams. At
           least the streams under control of the system (like _stdin_ , _stdout_ ,
           _stderr_) must be protected by locking the stream with _flockfile_().
           But the application itself could have done that, possibly in the
           same thread calling _fork_().  In this case, the process will
           deadlock.
    
           Alternatively, some libraries might have been able to supply just
           a _child_ routine that reinitializes the mutexes in the library and
           all associated states to some known value (for example, what it
           was when the image was originally executed). This approach is not
           possible, though, because implementations are allowed to fail
           _*_init_() and _*_destroy_() calls for mutexes and locks if the mutex
           or lock is still locked. In this case, the _child_ routine is not
           able to reinitialize the mutexes and locks.
    
           When _fork_() is called, only the calling thread is duplicated in
           the child process.  Synchronization variables remain in the same
           state in the child as they were in the parent at the time _fork_()
           was called. Thus, for example, mutex locks may be held by threads
           that no longer exist in the child process, and any associated
           states may be inconsistent. The intention was that the parent
           process could have avoided this by explicit code that acquires and
           releases locks critical to the child via _pthread_atfork_().  In
           addition, any critical threads would have needed to be recreated
           and reinitialized to the proper state in the child (also via
           _pthread_atfork_()).
    
           A higher-level package may acquire locks on its own data
           structures before invoking lower-level packages. Under this
           scenario, the order specified for fork handler calls allows a
           simple rule of initialization for avoiding package deadlock: a
           package initializes all packages on which it depends before it
           calls the _pthread_atfork_() function for itself.
    
           As explained, there is no suitable solution for functionality
           which requires non-atomic operations to be protected through
           mutexes and locks. This is why the POSIX.1 standard since the 1996
           release requires that the child process after _fork_() in a multi-
           threaded process only calls async-signal-safe interfaces.
    


## FUTURE DIRECTIONS



           The _pthread_atfork_() function may be formally deprecated (for
           example, by shading it OB) in a future version of this standard.
    


* * *