On 2001-Jul-03 22:50:18 -0700, Gregory Neil Shapiro <[EMAIL PROTECTED]> 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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to