Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!uwvax!cottage!lm From: lm@cottage.WISC.EDU (Larry McVoy) Newsgroups: comp.unix.questions Subject: Re: Fork and Join, Pipe in C Message-ID: <3760@spool.WISC.EDU> Date: Sat, 27-Jun-87 21:43:44 EDT Article-I.D.: spool.3760 Posted: Sat Jun 27 21:43:44 1987 Date-Received: Sun, 28-Jun-87 04:51:10 EDT References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <3754@spool.WISC.EDU> <22241@sun.uucp> Sender: news@spool.WISC.EDU Reply-To: lm@cottage.WISC.EDU (Larry McVoy) Followup-To: /dev/null@sun.com Organization: U of Wisconsin CS Dept Lines: 52 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. Sorry, Guy, but you are wrong. I suggest you do a little more background reading. I did some digging and came up with the paper which says that vfork() was for csh. The paper is "Converting a Swap based System to do Paging in an Architecture Lacking Page-Reference Bits" by Babaoglu & Joy, 1981 ACM. They specifically state that "We found the vast majority (over 80%) of all forks executed in the system were due to the command interpreter [ie, csh]." They go on to point out that they implemeted vfork() to get around this problem. It's all there on page 81, check it and see. To be sure that they were indeed talking about csh all one has to do is % cd /usr/src/bin/sh % fgrep vfork *.[ch] Which I did. No vfork(). The bottom line is: vfork was put in for csh. Specifically for csh. Not in part, not as a general tool, specifically for csh. $ > Irregardless of what the man page says (you listen to man pages? Use $ > the force, read the source) the definitive use of vfork() is how it is $ > used in csh. $ $ Bullshit. No Guy, not bullshit, true shit. Vfork() was put in specifically for csh. Any way that it is used in that program should be looked upon as a legitimate use of the system call. Saying otherwise is ridiculous. $ 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. Yeah - and just when is that work scheduled for completion? Real soon now, eh? This business about Unix documentation is a joke. Only trivial things are documented well. Anything complicated is, as has been pointed out before, addendumed by a lengthy bugs section or is just quiet. Case in point- I couldn't get to source for a weekend and my work came to screeching halt. I really hadn't realized how much I leaned on it but I'd say I pop over and look a couple of times a day. And I'm writing user level code. There's no excuse for that crap. Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy