Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!clyde!cbosgd!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon Allbery) Newsgroups: comp.unix.questions Subject: Re: Fork and Join, Pipe in C Message-ID: <2768@ncoast.UUCP> Date: Thu, 2-Jul-87 21:40:41 EDT Article-I.D.: ncoast.2768 Posted: Thu Jul 2 21:40:41 1987 Date-Received: Sat, 4-Jul-87 18:03:42 EDT References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> Reply-To: allbery@ncoast.UUCP (Brandon Allbery) Followup-To: comp.unix.questions Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 62 As quoted from <1028@bloom-beacon.MIT.EDU> by tytso@athena.mit.edu (Theodore Y. Ts'o): +--------------- | 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. +--------------- Nowhere does it say that it is VERSION dependent either, as you assert. If some machine implements copy-on-write, that implementation is assured by the man page to be able to make vfork() == fork(). +--------------- | 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. +--------------- If an early version of a system call has a bug which is documented, that bug becomes part of the interface and may not be fixed in an update, eh? Plexus documents late-found bugs in the release notes; this OBVIOUSLY (by your reasoning) casts them in stone and makes them wholly unfixable. At this point, if Plexus did things that way, I would start looking for another computer company. (Thank the Witness, they don't!) Should copy-on-write then require a wfork() call? --and if it has semantics that are subject to change, the change should be made into zfork() for the people who don't pay attention to its being listed as subject to change? Sure. Why don't we change all the existing system calls to V6 compatible and add new ones for the BSD (or SV or etc.) features? That way we make all the people who write programs that depend on V6 semantics happy. Nonsense. "Let's halt progress or make it painful, that way we can hide our heads in the sand when it happens." Do it elsewhere; *I* won't put up with it. Also -- just because a system program uses a system call in a way which is frowned upon does NOT make that usage correct. If a program uses a feature in a way that is documented as not being correct, EVEN IF THAT PROGRAM IS WRITTEN BY THE IMPLEMENTORS OF THE FEATURE, that program is wrong. The fact that vfork() was developed specifivally for csh is irrelevant; the manual page released to the public makes it clear that it is now a general feature. Again, doing otherwise gets ridiculous -- "ok, let's add cshfork() and cshexec() and telnetselect() and myprogramread() and ... system calls". The fact is that vfork, whatever its origins, was made GENERAL. Otherwise it would be named csh_only_fork() or something; and as I said above, that just isn't right. Adding a new system call should only be done if it's possible to make the system call general; adding a system call specifically for a single program's use is wasteful. ++Brandon -- ---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ---- Brandon S. Allbery !cbosgd!hal!ncoast!allbery ('til Aug. 1) aXcess Company {ames,mit-eddie,harvard,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 {well,sun,pyramid,ihnp4}!hoptoad!ncoast!allbery Mentor, OH 44060-4101 necntc!ncoast!allbery@harvard.HARVARD.EDU (Internet) +01 216 974 9210 ncoast!allbery@CWRU.EDU (CSnet -- if you dare) NCOAST ADMIN GROUP Brandon Allbery on 157/504 (Fidonet/Matrix/whatever) * ncoast -- Public Access UN*X -- (216) 781-6201, 24 hrs., 300/1200/2400 baud * * ncoast is proud to be carrying alt.all -- contact me for more information *