Index for Section 2

Alphabetical listing for F

Bottom of page

fork(2)
NAME
  fork, vfork - Create a new process

SYNOPSIS
  #include <unistd.h>

  pid_t fork(
	  void );

  pid_t vfork(
	  void );

  Application developers may want to specify an #include statement for
  <sys/types.h> before the one for <unistd.h> if programs are being developed
  for multiple platforms. The additional #include statement is not required
  on Tru64 UNIX systems or by ISO or XSH standards, but may be on other
  vendors' systems that conform to these standards.

STANDARDS
  Interfaces documented on this reference page conform to industry standards
  as follows:

  fork():  XSH4.0, XSH4.2, XSH5.0

  vfork():  XSH4.2, XSH5.0

  Refer to the standards(5) reference page for more information about
  industry standards and associated tags.

DESCRIPTION
  The fork() and vfork() functions create a new process (child process) that
  is identical to the calling process (parent process).

  The child process inherits the following from the parent process:

    ·  Environment

    ·  Close-on-exec flags

    ·  Signal-handling settings

    ·  Set user ID mode bit

    ·  Set group ID mode bit

    ·  Trusted state

    ·  Profiling on/off status

    ·  Nice value

    ·  All attached shared libraries

    ·  Process group ID

    ·  tty group ID

    ·  Current directory

    ·  Root directory

    ·  File mode creation mask

    ·  File size limit

    ·  Attached shared memory segments

    ·  Attached mapped file segments

    ·  All mapped regions, with the same protection and sharing mode as in
       the parent process

    ·  [Tru64 UNIX]  Message catalog descriptors. These are shared by parent
       and child processes until a modification is made.

    ·  The parent's policy and priority settings for the SCHED_FIFO and
       SCHED_RR scheduling policies (fork() call)

    ·  Open semaphores. Any semaphores open in the parent process are also
       open in the child process.

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

    ·  The child process has a unique process ID that does not match any
       active process group ID.

    ·  The parent process ID of the child process matches the process ID of
       the parent.

    ·  The child process has its own copy of the parent process's file
       descriptors. Each of the child's file descriptors refers to the same
       open file description with the corresponding file descriptor of the
       parent process.

    ·  The child process has its own copy of the parent's open directory
       streams. Each open directory stream in the child process may share
       directory stream positioning with the corresponding directory stream
       of the parent.

    ·  The child process has its own copy of the parent's message queue
       descriptors, each of which refers to the same open message description
       as referred to by the corresponding message queue descriptor of the
       parent.

    ·  All semadj values are cleared.

    ·  Process locks, text locks, and data locks are not inherited by the
       child process.

    ·  The child process' values of tms_utime, tms_stime, tms_cutime, and
       tms_cstime are set to 0 (zero).

    ·  Any pending alarms are cleared in the child process.

    ·  [Tru64 UNIX]  Any interval timers enabled by the parent process are
       reset in the child process.

    ·  Any signals pending for the parent process are cleared for the child
       process.

    ·  Address space memory locks established by the parent process through
       calls to mlockall() or mlock() are not inherited by the child process.

    ·  Per-process timers created by the parent process are not inherited by
       the child process.

    ·  Asynchronous input or asynchronous output operations started by the
       parent process are not inherited by the child process.

NOTES
  If a multithreaded process forks a child process, the new process contains
  a replica of the calling thread and its entire address space, possibly
  including the states of mutexes and other resources. Consequently, to avoid
  errors, the child process should only execute operations it knows will not
  cause deadlock.

  The fork() and vfork() functions have essentially the same implementation
  at the level of the operating system kernel but may differ in how they are
  supported through different libraries.  Some libraries, such as libpthread
  and libc, support fork handler routines that can acquire and release
  resources that are critical to the child process. Fork handlers therefore
  allow an application to manage potential deadlock situations that might
  occur between the parent and child processes. Fork handlers do not work
  correctly if the application calls vfork() to create the child process.
  Therefore, applications using libpthread and libc should call fork() to
  create a child process.

  For more information about fork handler routines, see pthread_atfork(3).
  For a complete list of system calls that are reentrant with respect to
  signals, see signal(4).

RETURN VALUES
  Upon successful completion, the fork() and vfork() functions return a value
  of 0 (zero) to the child process and return the process ID of the child
  process to the parent process. Otherwise, a value of -1 is returned to the
  parent, no child process is created, and errno is set to indicate the
  error.

ERRORS
  The fork() and vfork() functions set errno to the specified values for the
  following conditions:

  [EAGAIN]
      The limit on the total number of processes executing for a single user
      would be exceeded. This limit can be exceeded by a process with
      superuser privilege.

  [ENOMEM]
      There is not enough space left for this process.

SEE ALSO
  Functions: exec(2), exit(2), getpriority(2), getrusage(2), plock(2),
  ptrace(2), semop(2), shmat(2), sigaction(2), sigvec(2), umask(2), wait(2),
  nice(3), pthread_atfork(3), raise(3), times(3), ulimit(3)

  Files: signal(4)

  Others: standards(5)

Index for Section 2

Alphabetical listing for F

Top of page