Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!necntc!ames!schoch
From: schoch@ames.arpa (Steve Schoch)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <1968@ames.arpa>
Date: Fri, 26-Jun-87 19:48:18 EDT
Article-I.D.: ames.1968
Posted: Fri Jun 26 19:48:18 1987
Date-Received: Sat, 27-Jun-87 11:45:58 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <1006@bloom-beacon.MIT.EDU> <22181@sun.uucp>
Reply-To: schoch@ames.UUCP (Steve Schoch)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 18

In article <22181@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
> ...if you change the
>semantics of "vfork", it breaks - if somebody ports 4BSD and
>implements a better VM system, and makes vfork == fork (which the
>manual at least implies should be possible with such a VM system),
>without changing "csh", "csh" won't work.

Well, actually, it won't "break" csh, the "hashstat" built-in will just
not print anything.  It will still give (status == 0) and everything else
will work as before.  We found this out when we had a system where vfork
didn't work yet, so it just called fork() in the kernel.

The idea is that csh will use the "shared memory" feature of vfork while
it's there, but won't complain if it's not.  Of course, if some user gets
used to typing "hashstat" and expects it to print something, he will complain.
I don't know who uses that function anyway.

	Steve