fork, f_fork, or vfork Subroutine

Purpose

Creates a new process.

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)

Description

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 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, 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 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 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 subroutine.
  • The child process utime, stime, cutime, and cstime subroutines are set to 0. (For more information, see the getrusage , times, and vtimes subroutines.)
  • Any pending alarms are cleared in the child process. (For more information, see the incinterval, setitimer, and alarm subroutines.)
  • The set of signals pending for the child process is initialized to an empty set.
  • The child process can have its own copy of the message catalogue for the parent process.
Attention: If you are using the fork or vfork subroutines with an X Window System, 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.

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.

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.

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

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:

Item Description
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.
EPROCLIM If WLM is running, the limit on the number of processes or threads in the class may have been met.