Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!otc!metro!basser!boyd
From: boyd@basser.oz (Boyd Roberts)
Newsgroups: comp.unix.wizards
Subject: Re: UNIX fork
Message-ID: <1041@basser.oz>
Date: Wed, 7-Oct-87 03:15:38 EDT
Article-I.D.: basser.1041
Posted: Wed Oct  7 03:15:38 1987
Date-Received: Sat, 10-Oct-87 07:11:57 EDT
References: <125@quick.COM> <246@tifsie.UUCP> <8904@mimsy.UUCP>
Reply-To: boyd@basser.oz (Boyd Roberts)
Organization: Dept of Comp Sci, Uni of Sydney, Australia
Lines: 25


In article <125@quick.COM> srg@quick.COM (Spencer Garrett) writes:
>} 
>} 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().
>
>Indeed it does not.  That's why Berkeley has vfork().  A vfork call
>"borrows" the parent's memory instead of copying it.  The parent is
>kept in suspended animation while the child modifies the new environment.

What we have here is confusion between implementation & semantics.  If you
want a fast fork() implement it via ``copy-on-write''.  A rough benchmark
indicates that it's faster than vfork().  Anyway, vfork() is an atrocity!!

The fork/exec system call argument is bogus.  If you want such a call
then you'd better prepare yourself for the 1E9 arguments you'll have to supply
to make it usable.  ``We don't do that at KAOS!''




Boyd Roberts			boyd@basser.oz

``When the going gets wierd, the wierd turn pro...''