Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!decuac!felix!preston
From: preston@felix.UUCP (Preston Bannister)
Newsgroups: comp.os.minix
Subject: Re: fork
Message-ID: <85830@felix.UUCP>
Date: 7 Mar 89 03:41:46 GMT
References: <1989Mar3.174924.977@utzoo.uucp>
Sender: daemon@felix.UUCP
Lines: 49

From article <1989Mar3.174924.977@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> In article <85126@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes:
>>I've never been particularly fond of fork() as a primitive operation...
>>...In the "real" world, most fork() calls
>>are immediately followed with an exec() call.  The copy of the
>>process that fork() creates, exec() discards, so why bother making
>>the copy...
> 
> This is a common misconception.  The fact is, in the "real" world,
> very few fork() calls are *immediately* followed by an exec() call.
> There is almost always some manipulation of file descriptors, signals,
> etc. in between.

Oops...

What I _meant_ (as opposed to what I said :-) was that fork() calls are
almost always followed very closely by exec().  The point I am trying to
make is that the child-is-copy-of-parent semantic of fork() is irrelevant to
_most_ programs.

What most programs do between fork() and exec() is exactly what Henry has
listed above.  The semantics actually needed by most programs that use
fork()/exec() could be met by cloning the file, signal, etc. state from the
parent process without copying the *entire* data segment of the parent.

The semantics of the BSD vfork() call (kludge?) are close.  For those of you
who can't do "man vfork" :-) the vfork() call creates a "new system context"
for the child process without copying the entire parent's address space.
The child runs out of the parent's address space until it calls exec().
This is a kludge as the child is using the parent's _stack_ and could cause
major problems if exec() is not called in the same procedure as vfork().

Come to think of it, you could make a "safe" version of vfork() fairly easily:

	int safe_vfork(init_fn)
	  int (*init_fn)();
	{
	  int pid = vfork();
	  if (pid==0) _exit((*init_fn)(pid));
	  return pid;
	}
	
Where init_fn would call exec()...  did I miss something?	
--
Preston L. Bannister
USENET	   :	hplabs!felix!preston
BIX	   :	plb
CompuServe :	71350,3505
GEnie      :	p.bannister