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