Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!ctnews!pyramid!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: <22057@sun.uucp>
Date: Thu, 25-Jun-87 04:53:20 EDT
Article-I.D.: sun.22057
Posted: Thu Jun 25 04:53:20 1987
Date-Received: Sat, 27-Jun-87 01:08:53 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <1001@bloom-beacon.MIT.EDU>
Sender: news@sun.uucp
Lines: 38

> What about the overhead to update said shared file every time you
> execute a command?

Try it first, see how much the overhead really is, then complain.
Don't assume it'll have to be so large as to render abusing "vfork"
acceptable; it may very well not be noticeable.

> I think I prefer the "abuse" of the shared memory.

I hope you also prefer explaining to somebody why the function that
abuses "vfork" mysteriously fails under 4.nBSD, for some n > 3, or on
some box with a VM system that uses copy-on-write and thus implements
"vfork" as an alias for "fork" - and do so with NO complaints about
such implementations, as those complaints are completely unjustified.
I quote from the 4.3BSD manual page for "vfork":

	This system call will be eliminated when proper system sharing
	mechanisms are implemented.  Users should not depend on the memory
	sharing semantics of "vfork" as it will, in that case, be made
	synonymous to "fork".

Note especially the absence of the word "may" here - the word "will"
appears twice, so one presumes they wanted people to take this
warning seriously.  However, somebody decided this didn't apply to
them and went ahead and depended on those semantics anyway.

> The main purpose of vfork was to enhance csh's effiency anyway.

Yes, but the efficiency improvement due to eliminating a copy of the
entire data and stack segment was large; I've seen no evidence that
there would be any major efficiency improvement due to abusing
"vfork".  We're talking about a very small amount of data here (it
should fit into one frag), and that data is modified only if an
"exec" fails.  "exec"s shouldn't fail, in general, especially given
the C shell's path hashing.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com