Editing Fork (system call) (section)

===Vfork===
Vfork is a variant of fork with the same [[calling convention]] and much the same semantics, but only to be used in restricted situations. It originated in the [[Berkeley Software Distribution|3BSD]] version of Unix,<ref name="man|2|vfork|Linux">{{man|2|vfork|Linux}}</ref>{{r|netbsd-vfork}}<ref>{{cite encyclopedia |title=vfork(2) |encyclopedia=UNIX Programmer's Manual, Virtual VAX-11 Version |publisher=University of California, Berkeley |date=December 1979}}</ref> the first Unix to support virtual memory. It was standardized by POSIX, which permitted vfork to have exactly the same behavior as fork, but was marked obsolescent in the 2004 edition<ref name="posix-vfork">{{man|sh|vfork|SUS6}}</ref> and was replaced by [[Spawn (computing)#POSIX spawn functions|posix_spawn]]() (which is typically implemented via vfork) in subsequent editions.

When a vfork system call is issued, the parent process will be suspended until the child process has either completed execution or been replaced with a new executable image via one of the "[[Exec (system call)|exec]]" family of system calls. The child borrows the [[memory management unit]] setup from the parent and memory pages are shared among the parent and child process with no copying done, and in particular with no [[copy-on-write]] semantics;<ref name="posix-vfork"/> hence, if the child process makes a modification in any of the shared pages, no new page will be created and the modified pages are visible to the parent process too. Since there is absolutely no page copying involved (consuming additional memory), this technique is an optimization over plain fork in full-copy environments when used with exec. In POSIX, using vfork for any purpose except as a prelude to an immediate call to a function from the exec family (and a select few other operations) gives rise to [[undefined behavior]].<ref name="posix-vfork"/> As with vfork, the child borrows data structures rather than copying them. vfork is still faster than a fork that uses copy on write semantics.

[[UNIX System V|System V]] did not support this function call before System VR4 was introduced,{{citation needed|date=May 2015}} because the memory sharing that it causes is error-prone:

{{quote|''Vfork'' does not copy page tables so it is faster than the System V ''fork'' implementation. But the child process executes in the same physical address space as the parent process (until an ''exec'' or ''exit'') and can thus overwrite the parent's data and stack. A dangerous situation could arise if a programmer uses ''vfork'' incorrectly, so the onus for calling ''vfork'' lies with the programmer. The difference between the System V approach and the BSD approach is philosophical: Should the kernel hide idiosyncrasies of its implementation from users, or should it allow sophisticated users the opportunity to take advantage of the implementation to do a logical function more efficiently?|Maurice J. Bach<ref>{{Cite book |title=The Design of The UNIX Operating System |first=Maurice J. |last=Bach |publisher=Prentice–Hall |year=1986 |pages=291–292|bibcode=1986duos.book.....B }}</ref>}}

Similarly, the Linux [[man page]] for vfork strongly discourages its use:<ref name="man|2|vfork|Linux"/>{{Failed verification|date=November 2019|reason=quote not in source|talk=unfortunate, etc}}
{{quote|It is rather unfortunate that Linux revived this specter from the past. The BSD man page states: "This system call will be eliminated when proper system sharing mechanisms are  implemented. Users should not depend on the memory sharing semantics of vfork() as it will, in that case, be made synonymous to fork(2)."}}

Other problems with {{mono|vfork}} include [[Deadlock (computer science)|deadlock]]s that might occur in [[multi-threaded|multithreaded]] programs due to interactions with [[dynamic linking]].{{r|oracle}} As a replacement for the {{mono|vfork}} interface, POSIX introduced the {{mono|posix_spawn}} family of functions that combine the actions of fork and exec. These functions may be implemented as library routines in terms of {{mono|fork}}, as is done in Linux,{{r|oracle}} or in terms of {{mono|vfork}} for better performance, as is done in Solaris,<ref name="oracle">{{cite web |last=Nakhimovsky |first=Greg |date=May 2006 |title=Minimizing Memory Usage for Creating Application Subprocesses |url=http://www.oracle.com/technetwork/server-storage/solaris10/subprocess-136439.html |archive-url=https://web.archive.org/web/20190922113430/https://www.oracle.com/technetwork/server-storage/solaris10/subprocess-136439.html |archive-date=Sep 22, 2019 |website=Oracle Technology Network |publisher=[[Oracle Corporation]]}}</ref><ref>[[sourceforge:p/schillix-on/schillix-on/ci/default/tree/usr/src/lib/libc/port/threads/spawn.c|The OpenSolaris posix_spawn() implementation]]</ref> but the POSIX specification notes that they were "designed as [[system call|kernel operations]]", especially for operating systems running on constrained hardware and [[Real-time computing|real-time systems]].<ref>{{man|sh|posix_spawn|SUS}}</ref>

While the 4.4BSD implementation got rid of the vfork implementation, causing vfork to have the same behavior as fork, it was later reinstated in the [[NetBSD]] operating system for performance reasons.<ref name="netbsd-vfork">{{cite web |title=NetBSD Documentation: Why implement traditional vfork() |website=NetBSD Project |access-date=16 October 2013 |url=http://www.netbsd.org/docs/kernel/vfork.html}}</ref>

Some embedded operating systems such as [[uClinux]] omit fork and only implement vfork, because they need to operate on devices where copy-on-write is impossible to implement due to lack of a memory management unit.