Date: Thu, 05 Jul 2001 08:17:03 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: David Hill <djhill@novagate.net> Cc: freebsd-current@FreeBSD.ORG Subject: Re: system and (v)fork Message-ID: <20010705081703.G506@gsmx07.alcatel.com.au> In-Reply-To: <15170.44698.988817.714880@horsey.gshapiro.net>; from gshapiro@FreeBSD.ORG on Tue, Jul 03, 2001 at 10:50:18PM -0700 References: <20010704014703.4ec62b5f.djhill@novagate.net> <15170.44698.988817.714880@horsey.gshapiro.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-Jul-03 22:50:18 -0700, Gregory Neil Shapiro <gshapiro@FreeBSD.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010705081703.G506>