From owner-freebsd-current  Fri Apr 19 06:22:08 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id GAA04925
          for current-outgoing; Fri, 19 Apr 1996 06:22:08 -0700 (PDT)
Received: from elbe.desy.de (elbe.desy.de [131.169.82.208])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA04912
          for <current@FreeBSD.ORG>; Fri, 19 Apr 1996 06:21:57 -0700 (PDT)
From: Lars Gerhard Kuehl <lars@elbe.desy.de>
Date: Fri, 19 Apr 96 15:22:21 +0200
Message-Id: <9604191322.AA07511@elbe.desy.de>
To: smpatel@umiacs.umd.edu
Subject: Re: Changes for vfork()
Cc: current@FreeBSD.ORG
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


> We should briefly look over the source tree too.  Some brain-dead programs
> may rely on vfork() behavior (such as sleeping on the child, or altering
> the parent's address space)...

The current vfork() already doesn't allow the child to alter the parent's
address space and sometimes it's very desirable (or at least convenient)
if one can rely on the parent being suspended until the child calls
execve() or _exit().

I'd prefer somthing like a pid_t newfork(int suspend_parent),
fork implemented as

pid_t
fork()
{
  return newfork(0);
}

and so far anybody needs it vfork as

pid_t
vfork()
{
  return newfork(42);
}


fork1() is actually almost an implementation of that 'newfork()',
thus with only negligible changes in the kernel and libc code the
number of system calls could be decremented and nobody had to miss
anything.

	Lars