Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!hp4nl!charon!jack
From: jack@cwi.nl (Jack Jansen)
Newsgroups: comp.arch
Subject: Re: fork, spawn, vfork: an overview
Message-ID: <1940@charon.cwi.nl>
Date: 8 Aug 90 11:20:15 GMT
References: <25904@mimsy.umd.edu> <12382@encore.Encore.COM>
Sender: news@cwi.nl
Organization: AMOEBA project, CWI, Amsterdam
Lines: 30

A reasonably clean solution to the vfork() hack would be to split
fork in two: one call that creates a new kernel environment (u area,
etc), and another one that starts a new process in that environment.

You could then program like

	pre_fork();
	/*
	** From now on, all system calls we do refer to the kernel
	** state of the *new* process.
	*/
	close files;
	open other files;
	change signal;
	etc;
	pid = spawn("a.out", ....);
	/*
	** Here we're back in our own kernel environment again.
	*/

The only problem I see is that there are some calls for which it is
unclear what the semantics should be between the pre_fork() and the
spawn() call: sbrk() comes to mind. Also, if you crash between the
pre_fork() and the spawn it is unclear which of the two u areas you
would want to store in the coredump.
--
--
Een volk dat voor tirannen zwicht	| Oral:     Jack Jansen
zal meer dan lijf en goed verliezen	| Internet: jack@cwi.nl
dan dooft het licht			| Uucp:     hp4nl!cwi.nl!jack