Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!caen!spool.mu.edu!olivea!uunet!rufus!drake.almaden.ibm.com!drake
From: drake@drake.almaden.ibm.com
Newsgroups: comp.unix.aix
Subject: Re: vfork() (was Re: RS6000 questions/comments)
Keywords: compiler problems rs6000, vfork()
Message-ID: <889@rufus.UUCP>
Date: 29 Jun 91 05:57:24 GMT
Article-I.D.: rufus.889
References: <1991Jun27.221208.14845@kithrup.COM> <8903@awdprime.UUCP> <351@devnull.mpd.tandem.com>
Sender: news@rufus.UUCP
Distribution: usa
Organization: IBM Almaden Research Center
Lines: 21

In article <351@devnull.mpd.tandem.com> lance@mpd.tandem.com (Lance Hartmann) writes:
>                                                                The MAIN reason
>to use vfork() is when it is desired to spawn a child that does nothing
>but an execve().  With this scenario, it is unnecessary to copy the
>address space of the parent, so using vfork() is much more efficient.

While some systems with inefficient implementations of "fork()" require
a "vfork" mechanism in order for efficiency's sake, this is not a universal
situation.  Many systems have efficient implementations of "fork()",
making "vfork()" much less necessary, and completely eliminating the
issue mentioned in the referenced article.

The RISC System/6000's fork() implementation is quite efficient, making
"vfork" unnecessary for performance reasons.  Nonetheless, vfork() *is*
provided on the RISC System/6000, in the BSD compatibility library,
for the convenience of those porting BSD sources.


Sam Drake / IBM Almaden Research Center 
Internet:  drake@ibm.com            BITNET:  DRAKE at ALMADEN
Usenet:    ...!uunet!ibmarc!drake   Phone:   (408) 927-1861