Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!mordor!lll-tis!ames!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry F Aguirre)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <1764@oliveb.UUCP>
Date: Thu, 2-Jul-87 18:50:32 EDT
Article-I.D.: oliveb.1764
Posted: Thu Jul  2 18:50:32 1987
Date-Received: Sat, 4-Jul-87 08:38:08 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <3760@spool.WISC.EDU> <22255@sun.uucp> <3768@spool.WISC.EDU>
Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 37

In article <3768@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes:
>	So what's the big deal, Guy?  Obviously, csh will have to be fixed
>	when they throw out vfork().  But it won't be hard - they'll probably
>	have shared memory by then and people can do it that way.  Whatever
>	fix is used for csh can also be applied to similar programs.  So,
>	I say - use vfork() anyway you like, just be prepared to support
>	new VM models.  I don't see a big problem.  I mean, is all of
>	Berkeley running around chewing their nails over this?  Then
>	why are we?

I think what Guy is complaining about is that such code will not run on
a port of Unix that implements vfork in a different way.  This could be
either a new (4.4) version of BSD Unix or a port of the existing
versions to a new architecture.

Guy is posting from Sun and they are the ones who are always having
problems with null pointer dereferencing.  Somebody writes code that
runs fine on a Vax but core dumps on a sun.  The customer's response is
that Sun does not have a good port because the software ran perfectly on
a Vax.  Sun responds that the code is broken but the Vax just didn't
catch it.  Nobody is happy but DEC.

If someone implements a copy on write version of fork for their port of
4.[23] Unix and makes vfork the same as fork then they will be faced
with a number of programs that don't work correctly.  First off, the
csh.  Naturally they would like to avoid this.

My opinion is that they shouldn't have a vfork unless they can implement
it in a way that is compatible.  The memory sharing characteristic is a
documented and demonstrably used feature of vfork.  Either make a
separate vfork call that does share memory, wait the parent until exec,
etc. or don't claim to have vfork.

It was my understanding that, after a COW fork was implemented, vfork
would disappear, not be maintained as an alternate name for fork.

					Jerry Aguirre