Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!labrea!aurora!ames!oliveb!felix!preston
From: preston@felix.UUCP
Newsgroups: comp.arch,comp.unix.wizards,comp.os.minix
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <7672@felix.UUCP>
Date: Mon, 21-Sep-87 13:52:13 EDT
Article-I.D.: felix.7672
Posted: Mon Sep 21 13:52:13 1987
Date-Received: Sat, 26-Sep-87 07:44:01 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <7320@felix.UUCP> <838@usfvax2.UUCP>
Sender: daemon@felix.UUCP
Reply-To: preston@felix.UUCP (Preston Bannister)
Organization: FileNet Corp., Costa Mesa, CA
Lines: 69
Xref: utgpu comp.arch:2182 comp.unix.wizards:4123 comp.os.minix:1627

In article <838@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes:

>There is one thing about UNIX fork()-exec() that you've overlooked --
>after the fork(), the child process can set up the environment of the
>soon-to-be-exec'ed process by modifying its own environment.
>(Can you say `pipes, I/O redirection and current directory'? I knew you could.)

The point I was trying to make was that the fork() is typically
followed by an exec() call and that the full semantics of fork() are
not needed in those cases.  What I should have said :-) was that the
code executed between the fork() and exec() call typically does not
need the full semantics of fork().

An extreme example would be to imagine, say, a program that is using a
large amount of memory that wants to run some other program with the
output into a pipe that it would read.

The sequence would be something like:

	- open pipe
	- fork
	- assign one end of pipe for child's standard output
	- exec
	- (parent process now can read output of child from pipe)

The fork call is going to be awefully expensive, as a copy of the
entire data space of the parent will be made.  The code between the
fork() and exec() really doesn't need that copy, as all it does is make
a small modification to the context of the child process.

We need to factor out the management of process contexts (the set of
open files, mapping of signals, etc.) from the management of the
address/data space.

What I'm looking for is a good set of primitives.  From my point of
view, fork() and exec() are not really primitives, as they represent a
number of different operations.

Fork() can be factored to:

	- create new process context
	- copy parent process context to new context
	- create new address space
	- copy parent's data to new address space

Exec() can be factored to:

	- delete address/data space
	- create new address/data space
	- load code from given file
	- begin execution of code from file

(Did I miss something?)

Current typical uses of fork()/exec() could be replaced by:

	- create new process context
	- copy parent process context to new context
	(typical code to reassign files, signals, etc)
	- create new address/data space
	- load code from given file
	- begin execution of code from file

--
Preston L. Bannister
USENET	   :	ucbvax!trwrb!felix!preston
BIX	   :	plb
CompuServe :	71350,3505
GEnie      :	p.bannister