Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!ukc!warwick!cudcv
From: cudcv@daisy.warwick.ac.uk (Rob McMahon)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <371@sol.warwick.ac.uk>
Date: Tue, 14-Jul-87 10:11:25 EDT
Article-I.D.: sol.371
Posted: Tue Jul 14 10:11:25 1987
Date-Received: Fri, 17-Jul-87 05:58:51 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <21685@sun.uucp> <113@xyzzy.UUCP>
Reply-To: cudcv@sol.warwick.ac.uk (Rob McMahon)
Organization: Computing Services, Warwick University, UK
Lines: 34

In article <113@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes:
>If you think the operation is not
>interesting and common, note how many zillions of library routines use
>fork() or vfork() immediately followed by exec(), and provoke the kernel
>into doing all sorts of unnecessary work, even if that kernel implements
>copy-on-demand.

Searching through the sources yields

	libc/gen/popen
	     .../system
	libU77/chmod

popen needs to re-arrange all its file descriptors, so that leaves
system, and Fortran's chmod.

>
>I think it is clear that there "ought" to be a create_process(), despite
>the fact that it can be created out of fork() followed by exec(),
>because despite all tricks, fork() needs to get a process memory image
>from somewhere, and this will always come at some cost.
>

But this create_process() is going to have to let you rearrange file
descriptors, and probably catch signals to be of any real use.  I can
just imagine the interface---I think I'd rather have fork/exec and make
fork more efficient.

Rob

-- 
UUCP:   ...!mcvax!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick.daisy       ARPA:   cudcv@daisy.warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England