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: <3768@spool.WISC.EDU>
Date: Mon, 29-Jun-87 13:44:49 EDT
Article-I.D.: spool.3768
Posted: Mon Jun 29 13:44:49 1987
Date-Received: Tue, 30-Jun-87 06:16:24 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <3760@spool.WISC.EDU> <22255@sun.uucp>
Sender: news@spool.WISC.EDU
Reply-To: lm@cottage.WISC.EDU (Larry McVoy)
Organization: U of Wisconsin CS Dept
Lines: 41

Guy sez:
	vfork() was invented for all sorts of programs.

I sez:
	Guy is wrong, since vfork() was invented for csh.  On my side of the 
	ring we have the words of Bill Joy and others in published docs.
	(Note-  I never said that vfork() is only for csh, only that it was
	invented for csh.)

Guy sez:
	Larry is wrong, 'cause make & popen use vfork().

And now I sez:
	[Are we having fun yet????]

	Guy, don't be an ass.  We were talking about the *creation* of the
	system call.  

	You know, the funny thing is that I agree in principle with what Guy
	said in the first place - vfork() users probably ought not to pook
	about in their parent's address space.  What I didn't agree with,
	and what probably bothered other people, is Guy's statement that 
	"All programs that use vfork in this manner are brain damaged".
	That's an awfully strong statement and is just about impossible
	to back up.  All one has to do to disprove it is show one program
	for which that statement is false.  And the funny thing is that 
	the very first program to use vfork (csh) needed to be able to
	pook about in the parent's address space.  

	So what's the big deal, Guy?  Obviously, csh will have to be fixed
	when they throw out vfork().  But it won't be hard - they'll probably
	have shared memory by then and people can do it that way.  Whatever
	fix is used for csh can also be applied to similar programs.  So,
	I say - use vfork() anyway you like, just be prepared to support
	new VM models.  I don't see a big problem.  I mean, is all of
	Berkeley running around chewing their nails over this?  Then
	why are we?

	'Nuff said.  I hope.

Larry McVoy 	        lm@cottage.wisc.edu  or  uwvax!mcvoy