Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bellcore!uunet!cs.utexas.edu!jsq
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: qfork() (again)
Message-ID: <17454@cs.utexas.edu>
Date: 29 Jan 91 18:46:21 GMT
References: <16992@cs.utexas.edu> <17010@cs.utexas.edu> <17402@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 16
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <17402@cs.utexas.edu> michael@CS.UCLA.EDU (michael gersten) writes:
>Now, why was it removed? What is wrong with it?

vfork() wasn't removed; rather it was never added.  The base document
(/usr/group 1984 Standard) did not have vfork() but it did have fork().

There was no need for a second flavor of fork().  Standards and systems
in general should provide one sufficiently good way to perform a given
operation.  There were only two major arguments for vfork():  efficiency
of fork/exec, which is not a convincing argument, and that it provides a
form of sharing data space between two processes, which was judged to be
an undesirable form of providing such a facility.

Volume-Number: Volume 22, Number 86