Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!ames!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry F Aguirre)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <1696@oliveb.UUCP>
Date: Mon, 29-Jun-87 21:36:55 EDT
Article-I.D.: oliveb.1696
Posted: Mon Jun 29 21:36:55 1987
Date-Received: Wed, 1-Jul-87 03:45:11 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <21685@sun.uucp> <113@xyzzy.UUCP>
Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 52

In article <113@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes:
>That said, I agree that vfork is a horrible kludge.  What *should* have
>been coined is the ability to create a process running a new executable
>image in a single system call.  This is the only way the kernel can be
>*assured* (rather than simply having it hinted at) that this process
>creation will not involve the copying of any memory from the parent
>process.  The fork() operation is still interesting and necessary, and
>the exec() operation is still interesting and necessary, but so is the
>create_process() operation.  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.

I will have to go along with Guy on this one.  I have programed on
systems that that use a "creat_process" call and it is the most complex
system call in the whole system.  I have also scanned the Unix sources
and I have NOT found many uses of "fork" immediately followed by exec.
There is almost always some intermediate code between the two.

Let's take the case of csh, the reason vfork was created.  At the
minimum the csh will change the process group of the new process.  It
will also frequently have to close and open files.  Other programs "su"
have to deal with changes to the real and effective user and group IDs.
A more complete list would include:

	files				resource limits (CPU and memory)
	environment			umask
	priority			alarms
	signals				real and effective UID and GID
	process group			directory

I have probably missed some.  One could make a case for a
"create_process" with limited capabilities for optimizing the most
common case.  Except that the most common case is the most complex
one.  What options do you pass to the "create_process" call to tell it
that fd 1 should be closed and replaced by a pipe shared with the
parent?

Whatever features you decide not to include will be the ones most
desired by somebody else.  And, just when you think you have all
possible options built into your "create_process" call, someone will add
a new process characteristic.  You will then be faced with the prospect
of how to extend the "create_process" call to include the new options.
And of course you have to do this in a way that will be compatible with
old programs!

After looking at the parameters of "create_process" and the extended
parameters, and the optional extended extended parameters I considered
the fork exec of Unix a much cleaner and more elegant solution.

					Jerry Aguirre