Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <22181@sun.uucp>
Date: Fri, 26-Jun-87 14:52:11 EDT
Article-I.D.: sun.22181
Posted: Fri Jun 26 14:52:11 1987
Date-Received: Sat, 27-Jun-87 10:48:01 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <1006@bloom-beacon.MIT.EDU>
Sender: news@sun.uucp
Lines: 42

> For some n>3, /bin/csh will presumably be updated when vfork changes.
> If some VM system implements a copy-on-write fork and changes vfork on
> NOW, they will break csh.

No, they will NOT!  They will merely reveal that "csh" is ALREADY broken
by virtue of relying on something that was *explicitly documented* as
a quirk of the implementation that was not to be relied on.  It is
perfectly legitimate to provide a system with vfork == fork, and any
complaints from programmers whose improperly-written programs cease
to work should be redirected to /dev/null.

> /bin/csh is a system program.  USERS can write such programs at their
> own risk.

The trouble is that many users would squeal anyway, despite the fact
that they were explicitly told not to write this kind of program and
that they do so at their own risk.  (Consider the possibly-apocryphal
story of the person who bought and wrecked a Ferrari, and then sued
because (s)he wasn't told that it was a "high-performance car".)  It
appears that points such as this need to be reiterated over and over
again to ensure that people are aware of them.

Furthermore, the fact that "/bin/csh" is a system program doesn't
change the fact that there is no indication that, 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.

> A hashstat on my workstaion shows 26%.  Other hosts that I'm logged
> into show hit ratios of about 40%.  Our environment requires
> relatively long search paths.  

OK, but you still haven't provided any evidence that there would be a
major performance hit from using the file rather than abusing
"vfork".  Go implement it, test it, and *then* argue one way or the
other about whether it's a good thing to ignore what the manual says
about "vfork" or not.  (The burden of proof here is on the person who
argues that the manual's warning should be ignored.)
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com