Technical Reference: Base Operating System and Extensions, Volume 1

fork, f_fork, or vfork Subroutine

Libraries

fork, f_fork, and vfork: Standard C Library (libc.a)

Syntax

#include <unistd.h>

pid_t fork(void)

pid_t f_fork(void)

int vfork(void)

The fork subroutine creates a new process. The new process (child process) is an almost exact copy of the calling process (parent process). The child process inherits the following attributes from the parent process:

Environment
Close-on-exec flags (described in the exec (exec: execl, execle, execlp, execv, execve, execvp, or exect Subroutine) subroutine)
Signal handling settings (such as the SIG_DFL value, the SIG_IGN value, and the Function Address parameter)
Set user ID mode bit
Set group ID mode bit
Profiling on and off status
Nice value
All attached shared libraries
Process group ID
tty group ID (described in the exit (exit, atexit, or _exit Subroutine), atexit, or _exit subroutine, signal subroutine, and raise subroutine)
Current directory
Root directory
File-mode creation mask (described in the umask subroutine)
File size limit (described in the ulimit subroutine)
Attached shared memory segments (described in the shmat subroutine)
Attached mapped file segments (described in the shmat subroutine)
Debugger process ID and multiprocess flag if the parent process has multiprocess debugging enabled (described in the ptrace (ptrace, ptracex, ptrace64 Subroutine) subroutine).

The child process differs from the parent process in the following ways:

The child process has only one user thread; it is the one that called the fork subroutine.
The child process has a unique process ID.
The child process ID does not match any active process group ID.
The child process has a different parent process ID.
The child process has its own copy of the file descriptors for the parent process. However, each file descriptor of the child process shares a common file pointer with the corresponding file descriptor of the parent process.
All semadj values are cleared. For information about semadj values, see the semop subroutine.
Process locks, text locks, and data locks are not inherited by the child process. For information about locks, see the plock (plock Subroutine) subroutine.
If multiprocess debugging is turned on, the trace flags are inherited from the parent; otherwise, the trace flags are reset. For information about request 0, see the ptrace (ptrace, ptracex, ptrace64 Subroutine) subroutine.
The child process utime, stime, cutime, and cstime subroutines are set to 0. (For more information, see the getrusage (getrusage, getrusage64, times, or vtimes Subroutine), times, and vtimes subroutines.)
Any pending alarms are cleared in the child process. (For more information, see the incinterval (getinterval, incinterval, absinterval, resinc, resabs, alarm, ualarm, getitimer or setitimer Subroutine), setitimer (getinterval, incinterval, absinterval, resinc, resabs, alarm, ualarm, getitimer or setitimer Subroutine), and alarm (getinterval, incinterval, absinterval, resinc, resabs, alarm, ualarm, getitimer or setitimer Subroutine) subroutines.)
The set of signals pending for the child process is initialized to the empty set.
The child process can have its own copy of the message catalogue for the parent process.
The set of signals pending for the child process is initialized as an empty set.

Attention: If you are using the fork or vfork subroutines with an Enhanced X-Windows, X Toolkit, or Motif application, open a separate display connection (socket) for the forked process. If the child process uses the same display connection as the parent, the X Server will not be able to interpret the resulting data. See the Implementation Specifics section for more information.

The f_fork subroutine is similar to fork, except for:

It is required that the child process calls one of the exec functions immediately after it is created. Since the fork handlers are never called, the application data, mutexes and the locks are all undefined in the child process.

Implementation Specifics

Note: The information about the environment variable only applies to the Itanium-based platform.

The vfork subroutine is supported as a compatibility interface for older Berkeley Software Distribution (BSD) system programs and can be used by compiling with the Berkeley Compatibility Library (libbsd.a).

In the Version 4 of the operating system, the parent process does not have to wait until the child either exits or executes, as it does in BSD systems. The child process is given a new address space, as in the fork subroutine. The child process does not share any parent address space.

Attention: When using the fork or vfork subroutines with an Enhanced X-Windows, X Toolkit, or Motif application, a separate display connection (socket) should be opened for the forked process. The child process should never use the same display connection as the parent. Display connections are embodied with sockets, and sockets are inherited by the child process. Any attempt to have multiple processes writing to the same display connection results in the random interleaving of X protocol packets at the word level. The resulting data written to the socket will not be valid or undefined X protocol packets, and the X Server will not be able to interpret it.

Attention: Although the fork and vfork subroutine may be used with Graphics Library applications, the child process must not make any additional Graphics Library subroutine calls. The child application inherits some, but not all of the graphics hardware resources of the parent. Drawing by the child process may hang the graphics adapter, the Enhanced X Server, or may cause unpredictable results and place the system into an unpredictable state.

Note: Some Graphics Library subroutines, such as the winopen subroutine, implicitly create an X display connection. This connection may be obtained with the getXdpy subroutine.

For additional information, see the /usr/lpp/GL/README file.

Environment Variables

The default size of the register stack engine is 384K. If your application is core dumping with a SIGSEGV due to a register stack engine fault, you may need to increase the size of the register stack.

The size of the register stack can be changed via an environment variable. The size is specified in multiples of 1K. The change takes effect for any new processes, but it does not affect the current process' register stack. A value of zero reverts to the default stack size.

A value that is larger than the process limits allow causes a core dump when attempting to exec a new process.

Example:

export RSESTKSIZE=500

All child processes are now created with a 500K register stack size.

Note: The information about the environment variable only applies to the Itanium-based platform.

Return Values

Upon successful completion, the fork subroutine returns a value of 0 to the child process and returns the process ID of the child process to the parent process. Otherwise, a value of -1 is returned to the parent process, no child process is created, and the errno global variable is set to indicate the error.

Error Codes

The fork subroutine is unsuccessful if one or more of the following are true:

EAGAIN	Exceeds the limit on the total number of processes running either systemwide or by a single user, or the system does not have the resources necessary to create another process.
ENOMEM	Not enough space exists for this process.

Related Information

Subroutines Overview in AIX 5L Version 5.1 General Programming Concepts: Writing and Debugging Programs.

Process Duplication and Termination in AIX 5L Version 5.1 General Programming Concepts: Writing and Debugging ProgramsLK provides more information about forking a multi-threaded process.