vfork(2)

1VFORK(2)                   Linux Programmer's Manual                  VFORK(2)
2
3
4

NAME

6       vfork - create a child process and block parent
7

SYNOPSIS

9       #include <sys/types.h>
10       #include <unistd.h>
11
12       pid_t vfork(void);
13

STANDARD DESCRIPTION

15       (From  SUSv2  / POSIX draft.)  The vfork() function has the same effect
16       as fork(), except that the behaviour is undefined if the  process  cre‐
17       ated  by vfork() either modifies any data other than a variable of type
18       pid_t used to store the return value from vfork(), or returns from  the
19       function  in  which  vfork()  was  called,  or calls any other function
20       before successfully calling _exit() or one  of  the  exec()  family  of
21       functions.
22

LINUX DESCRIPTION

24       vfork(),  just  like  fork(2),  creates  a child process of the calling
25       process.  For details and return value and errors, see fork(2).
26
27       vfork() is a special case of clone(2).  It is used to create  new  pro‐
28       cesses  without  copying the page tables of the parent process.  It may
29       be useful in performance sensitive applications where a child  will  be
30       created which then immediately issues an execve().
31
32       vfork()  differs  from fork() in that the parent is suspended until the
33       child makes a call to execve(2) or _exit(2).  The child shares all mem‐
34       ory  with  its parent, including the stack, until execve() is issued by
35       the child.  The child must not return from the current function or call
36       exit(), but may call _exit().
37
38       Signal  handlers  are inherited, but not shared.  Signals to the parent
39       arrive after the child releases the parent's memory.
40

HISTORIC DESCRIPTION

42       Under Linux, fork() is implemented using copy-on-write  pages,  so  the
43       only  penalty  incurred  by  fork()  is the time and memory required to
44       duplicate the parent's page tables, and to create a unique task  struc‐
45       ture  for  the  child.   However,  in  the  bad old days a fork() would
46       require making a complete copy of the caller's data space, often  need‐
47       lessly,  since  usually immediately afterwards an exec() is done. Thus,
48       for greater efficiency, BSD introduced the vfork()  system  call,  that
49       did  not  fully  copy the address space of the parent process, but bor‐
50       rowed the parent's memory  and  thread  of  control  until  a  call  to
51       execve()  or  an  exit occurred. The parent process was suspended while
52       the child was using its resources.  The use of vfork() was tricky:  for
53       example,  not  modifying data in the parent process depended on knowing
54       which variables are held in a register.
55

BUGS

57       It is rather unfortunate that Linux revived this spectre from the past.
58       The  BSD  manpage  states:  "This  system  call will be eliminated when
59       proper system sharing mechanisms  are  implemented.  Users  should  not
60       depend  on  the memory sharing semantics of vfork() as it will, in that
61       case, be made synonymous to fork()."
62
63       Details of the signal handling are obscure and differ between  systems.
64       The  BSD  manpage states: "To avoid a possible deadlock situation, pro‐
65       cesses that are children in the middle of  a  vfork()  are  never  sent
66       SIGTTOU  or  SIGTTIN  signals; rather, output or ioctls are allowed and
67       input attempts result in an end-of-file indication."
68

HISTORY

70       The vfork() system call appeared in 3.0BSD.  In 4.4BSD it was made syn‐
71       onymous  to  fork() but NetBSD introduced it again, cf. http://www.net‐
72       bsd.org/Documentation/kernel/vfork.html .  In Linux, it has been equiv‐
73       alent  to  fork()  until  2.2.0-pre6  or so. Since 2.2.0-pre9 (on i386,
74       somewhat later on other architectures)  it  is  an  independent  system
75       call. Support was added in glibc 2.0.112.
76

CONFORMING TO

78       4.3BSD, POSIX.1-2001.  The requirements put on vfork() by the standards
79       are weaker than those put on fork(), so an implementation where the two
80       are  synonymous is compliant. In particular, the programmer cannot rely
81       on the parent remaining blocked until a call of execve() or _exit() and
82       cannot rely on any specific behaviour w.r.t. shared memory.
83

LINUX NOTES

85       Fork handlers established using pthread_atfork(3) are not called when a
86       multithreaded  program  employing  the  NPTL  threading  library  calls
87       vfork().   Fork handlers are called in this case in a program using the
88       LinuxThreads threading library.  (See pthreads(7) for a description  of
89       Linux threading libraries.)
90