vfork man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

fork(2)								       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 stan‐
       dards 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: Envi‐
       ronment	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 Cur‐
       rent 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	corre‐
       sponding	 file descriptor of the parent process.	 The child process has
       its own copy of the parent's open directory streams. Each  open	direc‐
       tory 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  par‐
       ent 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 asyn‐
       chronous output operations started by the parent process are not inher‐
       ited by the child process.

NOTES
       If  a multithreaded process forks a child process, the new process con‐
       tains a replica of the calling thread and  its  entire  address	space,
       possibly	 including  the	 states of mutexes and other resources. Conse‐
       quently, to avoid errors, the child process should only execute	opera‐
       tions it knows will not cause deadlock.

       The  fork() and vfork() functions have essentially the same implementa‐
       tion 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 han‐
       dlers therefore allow an application to manage potential deadlock situ‐
       ations  that  might  occur between the parent and child processes. Fork
       handlers do not work correctly if the application calls vfork() to cre‐
       ate  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 reen‐
       trant 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:  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.  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)

								       fork(2)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net