Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: michael@CS.UCLA.EDU (michael gersten)
Newsgroups: comp.std.unix
Subject: Re: qfork() (again)
Message-ID: <17402@cs.utexas.edu>
Date: 25 Jan 91 03:25:13 GMT
References: <16875@cs.utexas.edu> <16992@cs.utexas.edu> <17010@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: UCLA Computer Science Department
Lines: 35
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: michael@CS.UCLA.EDU (michael gersten)

In article <17010@cs.utexas.edu> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
>
>In article <16992@cs.utexas.edu> peter@ficc.ferranti.com (Peter da Silva) writes:
>>In article <16875@cs.utexas.edu> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>> We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
>>> because it was not necessary, given a decent implementation of fork().
>>POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
>>environments a "decent implementation of fork" is quite difficult ...
>
>Excuse me, but you're quite wrong.  P1003 decided deliberately that we
>(I was there) would not compromise the (1003.1) interface in order to
>accommodate "layered" implementations, for example on non-UNIX based
>operating system kernels.


May I humbly ask what was wrong with vfork?

As I understand it, vfork's semantics was a virtual fork--
conceptually two execution threads would return from the call,
and they may or may not be sharing data space--any program
that relied on one or the other was by definition broken.

Now, with that definition, vfork() is pretty trivial to implement,
even on a naked 68000 with no mmu. And on better, more complete
systems, it can be identical to fork.

So its a call that is at least, if not more, efficient on a larger
variety of hardware platforms.

Now, why was it removed? What is wrong with it?

Volume-Number: Volume 22, Number 82