In message <199804141703.KAA14300@lestat.nas.nasa.gov>  Jason Thorpe wrote:
> On Tue, 14 Apr 1998 15:10:00 +0930 
>  Ian Dall <Ian.Dall@dsto.defence.gov.au> wrote:
> 

[...]

> vfork() can NOT be implemented as:
> 
> pid_t
> vfork()
> {
> 
> 	return (fork());
> }
> 
> ...because vfork() has always been defined to block the parent until
> the child either (a) exits, or (b) execs.
> 
> If you change that, you're looking at breaking a good number of applications.

Just for the record (I think vfork has enough benefits without addresspace
sharing):

If no dirty  tricks are used, than you break only those applications
where the child sets something up  (a named pipe or creates a file, setting
tty-states ... ) on which the parent depends. In those cases you could do:

pid_t
vfork()
{
    pid_t pid;
    int syncpipe[2];
    int dummy;

    pipe(syncpipe); /* error handling */

    switch(pid=fork()) {
	case 0: 
		close(syncpipe[0]);
		fcntl(syncpipe[1],F_SETFD,1);
		break;
	case -1: break;
	default:
		close(syncpipe[1]);
		read(syncpipe[0],&dummy,1);
		close(syncpipe[0]);
		break;
    }
    return pid;
}

In real-life of course you would dup2 the pipe to some high numbers to avoid
confusion.
Yes this works (some systems just don't have vfork ...).

I think relying on vfork to share address-space is bad-practice and should
be discouraged. Expecting that it doesn't share fails unfortunatly too.

I think all effort should be directed to making fork()'s COW cheaper so that
the remaing benefit of vfork is that it blocks the parent until the 
child execs, which saves a lot of COW's for the parent process. 
(It still gets a pagefault, but thats all, if it is done right it 
may even get away with one pagefault per writeable memory object).
I don't see how sharing address space would gain significant performance,
if this would work. 
I know that NetBSD is not there yet. I also think that NetBSD has the 
hardest job of all Operating systems (as it do run on the widest varity
if hardware), so it'll take some time till we get there.
On the other hand it forces us to make a good design ... which leads to 
a smaller user-base (see <http://people.netscape.com/jwz/worse-is-better.html>
why M$sh*t is so succesfull).

My $.02:
Keep vfork as it is now, until we have a cheap enough COW version of it.
Document that the existing behaviour will go away and give applications a
way of figuring out which one is active. (A well known define for source
code and a sysctl for binaries ...).
We have quick vfork now, and implementing a way to detect it shouldn't
take too much time. Than start working on the vm system ...

Stefan

> 
> Jason R. Thorpe                                       thorpej@nas.nasa.gov
> NASA Ames Research Center                            Home: +1 408 866 1912
> NAS: M/S 258-5                                       Work: +1 650 604 0935
> Moffett Field, CA 94035                             Pager: +1 415 428 6939

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---