Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!aurora!labrea!decwrl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.arch,comp.unix.wizards
Subject: Re: UNIX fork
Message-ID: <909@mcgill-vision.UUCP>
Date: Tue, 17-Nov-87 18:17:45 EST
Article-I.D.: mcgill-v.909
Posted: Tue Nov 17 18:17:45 1987
Date-Received: Fri, 27-Nov-87 00:02:14 EST
References: <125@quick.COM> <246@tifsie.UUCP> <8904@mimsy.UUCP> <179@aiva.ed.ac.uk>
Organization: McGill University, Montreal
Lines: 47
Xref: mnetor comp.arch:2995 comp.unix.wizards:5577

In article <179@aiva.ed.ac.uk>, richard@aiva.ed.ac.uk (Richard Tobin) writes:
> In article <8904@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>> Vfork borrows the parent's *memory*; this does not include its
>> kernel space information, such as file descriptors.

True, though file descriptors are a bad example - the child gets clones
of the parent's file descriptors with vfork() just as it does with
fork().

> Indeed, it would usually be pointless to muck about with [the
> parent's stdio streams], because they're going to disappear when the
> child execs another program.  The things that are shared between the
> parent and child are just the things that don't survive an exec.

In fact, this is the whole point of vfork() - share the things that can
be given back on exec().

However, it is not quite "pointless" to mess with stdio streams.
Consider the following program:

main()
{
 printf("xxx");
 if (vfork() == 0)
  { printf("yyy");
    exec(....);
    _exit(1);
  }
 printf("zzz\n");
}

(note the lack of fflush()es).  This will print xxxyyyzzz\n, for the
printf in the child is merely buffered - and the buffer is shared.  If
we add fflush(stdout); after printf("yyy"); then we get xxxyyyzzz\n as
before, though for different reasons: the child's fflush empties the
stdio buffer, which remains emptied when the parent gets the memory
back.

Of course, it *is* a bad idea for the child to mess around with
anything the parent owns (such as is done in the above code), because
code depending on the sharing semantics will break when someone finally
fixes fork() to do a proper copy-on-write fork, and thus eliminates the
need for vfork() and makes it equivalent to fork().

					der Mouse

				(mouse@mcgill-vision.uucp)