From owner-freebsd-hackers Mon Jun 17 22:12:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA28724 for hackers-outgoing; Mon, 17 Jun 1996 22:12:46 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA28718 for ; Mon, 17 Jun 1996 22:12:43 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id WAA02021; Mon, 17 Jun 1996 22:12:06 -0700 (PDT) To: Michael Hancock cc: hackers@freebsd.org Subject: Re: vfork cow? In-reply-to: Your message of "Tue, 18 Jun 1996 11:39:41 +0900." Date: Mon, 17 Jun 1996 22:12:06 -0700 Message-ID: <2019.835074726@time.cdrom.com> From: "Jordan K. Hubbard" 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? Uh, vfork() has always used COW semantics - it just shared data space with the parent in the early days and was considered dangerous if you had an application which vfork()'d but didn't exec() right away, hanging around and changing variables instead. Nowadays it's a bit different whereas fork() uses COW semantics by default and neither *fork() shares its parent's data space (for that, see rfork(2) in -current). In this environment, vfork() loses its reason to exist. Jordan