From owner-freebsd-hackers  Mon Jun 17 20:24:39 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA21091
          for hackers-outgoing; Mon, 17 Jun 1996 20:24:39 -0700 (PDT)
Received: from kithrup.com (kithrup.com [205.179.156.40])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA21086
          for <hackers@freebsd.org>; Mon, 17 Jun 1996 20:24:31 -0700 (PDT)
Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id UAA04977; Mon, 17 Jun 1996 20:24:30 -0700
Date: Mon, 17 Jun 1996 20:24:30 -0700
From: Sean Eric Fagan <sef@kithrup.com>
Message-Id: <199606180324.UAA04977@kithrup.com>
To: hackers@freebsd.org, michaelh@cet.co.jp
Subject: Re: vfork cow?
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>I didn't realize that vfork in 4.4bsd was implemented with copy-on-write
>semantics until I read the deamon book.  Is it really going to be a
>deprecated call kept around for compatibility?

vfork() is *not* deprecated!  Doing so would break tons o' stuff ;).

vfork's main difference from fork() is that the parent is waits for the
child to exec or exit.  SysVrX (X < 4) systems that didn't have vfork had to
do all sorts of fun things to synchronize; using vfork() makes the code
*much* simpler.

Keith or Kirk mentioned, at one point, possibly going back to the old
semantics; this is useful for large-memory processes, depending on the
implementation.  (John and David just did some work to improve pmap_copy,
which helps address this issue.  However, let's get a few processes with
2GBytes of address space active, and see how well it does ;).)

Sean.