Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!mordor!lll-tis!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <22327@sun.uucp>
Date: Mon, 29-Jun-87 14:40:28 EDT
Article-I.D.: sun.22327
Posted: Mon Jun 29 14:40:28 1987
Date-Received: Tue, 30-Jun-87 04:39:13 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <1028@bloom-beacon.MIT.EDU>
Sender: news@sun.uucp
Lines: 61

> 1)  /bin/csh is a system program, not a user program.  It never says
> that system programs distributed by BSD may not use this call, and the
> BUGS entry of programs that use this call do not consider the fact that
> they use vfork a bug.  

Dammit, nobody was saying that the fact that they use "vfork" *was* a
bug!  The fact that they abuse a side-effect of the implementation of
"vfork", in a fashion that the manual page *explicitly says not to*,
is the problem.

> 2)  The man page implies that future versions of *BSD* may change vfork.
> Nowhere in the man page does it say that it is IMPLEMENTATION
> dependant.

It should be fairly clear from the manual page that the *intent* of
"vfork" was NOT to permit sharing of address space between parent and
child, but to reduce the ovehead of creating a child.

> 3)  Since the man page specifcally goes into painful detail how vfork
> works, the schemamtics of vfork have become part of the BSD 4.3 system
> interface.  Any implementation that changes the meaning of vfork is not
> "FULL" BSD 4.3.

The manual page also specifically goes into detail about how you are
NOT supposed to depend on those semantics; this would appear to
indicate that the fact that the current 4BSD implementation of
"vfork" causes the parent and child to temporarily share memory was
most definitely NOT intended to be a feature of "vfork".  Manual
pages will sometimes describe implementation details without making
them part of the specification.

> All of the sources that I (and other people) have consulted say that
> vfork was implemented specifically for /bin/csh.  Your arguments simply
> point to the source code of various programs/routines, like make and 
> popen.  Which came first, the chicken or the egg?  I (and several other
> people) have documentation that vfork was implemented specifically and
> originally for /bin/csh.  Do us the favor of finding some documented
> evidence to the contrary if you believe otherwise.

What does "implemented specifically for '/bin/csh'" mean?  Does it
mean that it was not intended to be used by anybody else?  Obviously
not, since they documented it in enough detail for others to use
(AND, I repeat, in enough detail to strongy discourage people from
abusing the fact that the implementation caused the parent and the
child to share portions of their data space!), and since it was used
elsewhere.

The only way in which it was "implemented specifically for
'/bin/csh'" was that the program that caused them to *notice* that
providing "vfork" would increase performance was "/bin/csh".

Sigh.  If anybody STILL thinks that it's OK to rely on the shared
memory that the current "vfork" implementation provides, and that
this shared memory is a feature of the specification, not a
characteristic of the implementation, would they please explain why
the manual page specifically tells you NOT to rely on this?  All the
people who seem eager to consider the implementation to be the
specification have failed to address this point.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com