From owner-freebsd-current Wed Jul 4 15:17:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 0559B37B401 for ; Wed, 4 Jul 2001 15:17:10 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id IAA04135; Thu, 5 Jul 2001 08:17:06 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01K5KCTDA480VNZX4K@cim.alcatel.com.au>; Thu, 5 Jul 2001 08:16:52 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f64MH3867509; Thu, 05 Jul 2001 08:17:03 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Thu, 05 Jul 2001 08:17:03 +1000 From: Peter Jeremy Subject: Re: system and (v)fork In-reply-to: <15170.44698.988817.714880@horsey.gshapiro.net>; from gshapiro@FreeBSD.ORG on Tue, Jul 03, 2001 at 10:50:18PM -0700 To: David Hill Cc: freebsd-current@FreeBSD.ORG Mail-Followup-To: David Hill , freebsd-current@FreeBSD.ORG Message-id: <20010705081703.G506@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20010704014703.4ec62b5f.djhill@novagate.net> <15170.44698.988817.714880@horsey.gshapiro.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2001-Jul-03 22:50:18 -0700, Gregory Neil Shapiro wrote: >djhill> Why wouldn't he use vfork() instead of fork()? > >If there is anything that modifies memory or file descripts between the >fork() and exec*() call, you can't use vfork(). To expand on Gregory's answer somewhat: Traditionally, fork(2) copied the complete address space to provide two identical copies of the process. This was a fairly expensive operation, especially if the process was large and the child was just going to call exec(2). vfork(2) optimised this process by avoiding the address space duplication. Instead the parent process is stopped and the child executes in the _parents_ address space until it issues an exec(), at which point the child is given its own address space containing the newly exec'd image. The parent then continues. The child code between the fork() and subsequent exec() must be carefully written because any changes to memory (including stack) or open files will also be reflected in the parent. Modern Unices (including 4.4BSD derivatives) avoid most of the inefficiences associated with fork() by just copying the page tables: Both processes are given separate address spaces, but they both point to the same physical memory or swap. All pages are marked `read-only' so that any writes to them will trap - at which point that page will be duplicated and marked R/W for both processes. This approach provides most of the efficiency gains offered by vfork(), without the child-can-affect-the-parent oddities. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message