Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!husc6!bloom-beacon!tytso
From: tytso@athena.mit.edu (Theodore Y. Ts'o)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <1027@bloom-beacon.MIT.EDU>
Date: Sat, 27-Jun-87 17:54:51 EDT
Article-I.D.: bloom-be.1027
Posted: Sat Jun 27 17:54:51 1987
Date-Received: Sun, 28-Jun-87 02:44:16 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <3754@spool.WISC.EDU> <22241@sun.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: tytso@athena.mit.edu (Theodore Y. Ts'o)
Organization: Massachusetts Institute of Technology
Lines: 66

In article <22241@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>> but I believe vfork() was implemented *specifically* for csh.
>
>"vfork" was implemented for the benefit of various programs, "csh"
>among them.  However, the fact that the current implementations of
>"vfork" give you a limited form of shared memory was purely a
>consequence of the implementation; it was not a "feature" stuck in
>for the benefit of any program, and if it disappears *nobody* has the
>right to complain *at all*.
>
>Unfortunately, some person who decides that warnings in the manual
>page.....

*WHAT* warnings in the man pages?  The only thing coming close to what
you're saying is the BUGS entry where it says that it "will be
eliminated when proper system sharing mechanisms are implemented."
This implies that future *VERSIONS* of BSD have the right to change
the meaning of vfork, NOT future *IMPLEMENTATIONS*.  Since /bin/csh is
maintained by Berkeley, when they change vfork, I expect they will
update /bin/csh as well.

>Bullshit.  First of all, the line "Use the force, read the source" is
>descriptive of a deficiency in UNIX, not of an advantage of UNIX.
>One is forced to read the source in some cases because the UNIX
>documentation is either 1) incorrect, 2) unclear, or 3) incomplete.
>The UNIX documentation *should* be correct, clear, and complete; the
>fact that it isn't merely means more work should be done on it.

It's been said that UNIX is a OS writen by, and for, systems
programers.  Systems programmers writing documentation? :-)
Seriously, I know they should, but you may be expecting a little bit
too much of human nature.....


>Second of all, in this particular case the UNIX documentation *is*
>correct, clear, and complete.  It tells you that these semantics of
>"vfork" are a side-effect of the current implementation, not a

Where?  See above.  I think that you differ with everybody else on the
interpretation of the man pages.  But at least mine (BSD 4.3) says
absolutely nothing about vfork being implementation dependant.  You
may be reading a little bit too much into the man page here.

> [flames about how programs that know too much about the
> implementation of UNIX and rely upon them are broken]

Fine, but how do you know what is a "implementation detail" and what
is a part of the system call standard interface.  By placing a
description of how vfork works in the man pages, that becomes part of
the interface.  If I write a program that uses vfork in a clever way,
but one that is COMPLETELY DOCUMENTED IN THE MAN PAGES, I expect that it
should work in any implementation of UNIX that claims to be BSD 4.3.
If it doesn't work, it isn't 4.3.  Sure it should have been made
more portable.  But when you have a program like /bin/csh, which is
ditributed under the assumption that it will run only under 4.3, 
(since it's distributed with it :-8) it's perfectly justified, don't
you think? 

>	Guy Harris
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Theodore Ts'o                           |
mit-eddie!mit-athena!tytso              |     M.I.T.,
tytso@athena.mit.edu                    |        P.h.D.,
3 Ames St., Cambridge, MA 02139         |            M.O.N.E.Y.!
                                        |
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+