PTHREAD_ATFORK(3) | Library Functions Manual | PTHREAD_ATFORK(3)

# NAME

`pthread_atfork` —
register handlers to be called when process forks

# LIBRARY

Standard C Library (libc, -lc)

# SYNOPSIS

`#include <pthread.h>`

int
`pthread_atfork`(void (*prepare)(void), void (*parent)(void), void (*child)(void));

# DESCRIPTION

The `pthread_atfork`() function registers the provided handler functions to be called when the fork(2) function is called. Each of the three handlers is called at a different place in the fork(2) sequence. The prepare handler is called in the parent process before the fork happens, the parent handler is called in the parent process after the fork has happened, and the child handler is called in the child process after the fork has happened. The parent and child handlers are called in the order in which they were registered, while the prepare handlers are called in reverse of the order in which they were registered.

Any of the handlers given may be `NULL`.

The intended use of `pthread_atfork`() is to provide a consistent state to a child process from a multithreaded parent process where locks may be acquired and released asynchronously with respect to the fork(2) call. Each subsystem with locks that are used in a child process should register handlers with `pthread_atfork`() that acquires those locks in the prepare handler and releases them in the parent handler.

# RETURN VALUES

The `pthread_atfork`() function returns 0 on success and an error number on failure.

# ERRORS

The following error code may be returned:

[`ENOMEM`]
  Insufficient memory exists to register the fork handlers.

# SEE ALSO

fork(2), pthread_mutex(3), signal(7)

# STANDARDS

The `pthread_atfork`() function conforms to IEEE Std 1003.1c-1995 (“POSIX.1c”).

# HISTORY

The `pthread_atfork`() function first appeared in NetBSD 2.0.

# CAVEATS

After calling fork(2) from a multithreaded process, it is only safe to call async-signal-safe functions until calling one of the exec(3) functions. The `pthread_*`() functions are not async-signal-safe, so it is not safe to use such functions in the child handler. POSIX does not mandate that `pthread_mutex_unlock`() be async-signal-safe, but it is in NetBSD and thus safe to use within the child handler.

# BUGS

There is no way to unregister a handler registered with `pthread_atfork`().

July 18, 2014 | NetBSD 9.3