From owner-freebsd-hackers  Mon Jun 17 22:49:48 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA01545
          for hackers-outgoing; Mon, 17 Jun 1996 22:49:48 -0700 (PDT)
Received: from xi.dorm.umd.edu (root@morrison-c21.aa.net [204.157.220.153])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA01540
          for <hackers@freebsd.org>; Mon, 17 Jun 1996 22:49:45 -0700 (PDT)
Received: from localhost (smpatel@localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.5/8.6.12) with SMTP id WAA00696; Mon, 17 Jun 1996 22:49:20 -0700 (PDT)
Date: Mon, 17 Jun 1996 22:49:19 -0700 (PDT)
From: Sujal Patel <smpatel@umiacs.umd.edu>
X-Sender: smpatel@xi.dorm.umd.edu
To: Sean Eric Fagan <sef@kithrup.com>
cc: michaelh@cet.co.jp, hackers@freebsd.org
Subject: Re: vfork cow?
In-Reply-To: <199606180449.VAA06907@kithrup.com>
Message-ID: <Pine.NEB.3.92.960617224617.494E-100000@xi.dorm.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Mon, 17 Jun 1996, Sean Eric Fagan wrote:

> Any such program will not work under FreeBSD, because it doesn't do this!

Actually, csh still has this code enabled..  If you make vfork() share the
parent's memory (trivial with the current design), it actually does do as
it was intended back in the dark ages.

> Also, I don't think "many" programs ever depended on this.  csh did, and it
> was fixed a long time ago.  (The fact that the 4.2 allowed the child process
> to modify its parent's memory was a bug, and was listed as such in the
> manpage.)

I am with you 100% on this Sean...  BUT!  There are problems like the
dreaded "Suspended (TTY Output)" bug in csh, that will mandate that
vfork() be available for the forseeable future.


Sujal