Re: kern/49017: vfork does not suspend all threads

[Nico Williams <Nico.Williams%twosigma.com@localhost>]

The following reply was made to PR kern/49017; it has been noted by GNATS.

From: Nico Williams <Nico.Williams%twosigma.com@localhost>
To: <gnats-bugs%netbsd.org@localhost>
Cc: 
Subject: Re: kern/49017: vfork does not suspend all threads
Date: Thu, 6 Apr 2017 15:36:41 +0000

 Martin Husemann <martin%duskware.de@localhost> wrote:
 > On Wed, Apr 05, 2017 at 04:26:04PM -0400, Christos Zoulas wrote:
 > > On Apr 5,  7:20pm, martin%duskware.de@localhost (Martin Husemann) wrote:
 > > -- Subject: Re: kern/49017: vfork does not suspend all threads
 > > 
 > > |  Using vfork() in a program with multiple active threads is madness,
 > > |  posix_spawn() is the only sensible way.
 > > 
 > > Why is that? We allow it, so it should do something reasonable/useful...
 > > Or we should not allow it...
 > 
 > We now have two processes with active threads each and a shared vmpspace.
 > This sounds like completely out of spec for the unix process model to me
 > and I'd call it madness.
 
 "sounds like"
 
 Everything that BSD ever did prior to the advent of POSIX and other such
 standards... was "completely out of spec" for Unix.
 
 That is precisely how one innovates: by stepping outside the spec.
 
 Your rejection of this seems emotional rather than thought out.  It happens
 because we're humans; naturally I do this too sometimes.
 
 I urge you to read what I've written rather than merely react to the one-line
 summary of the proposal.
 
 Please leave behind the idea that vfork() is dangerous.  It absolutely is not.
 Decades of experience with it bears that out:
 
  - posix_spawn() on Linux, Solaris, Illumos, NetBSD (before posix_spawn()
    became a system call), and other BSDs -- all use vfork() internally
 
  - many app suse vfork(), including, famously, csh (now, I know, csh is evil,
    but that it successfully and safely uses vfork() cannot be denied)
 
  - you can search online nowadays for more vfork()-using code, and you can look
    at https://github.com/famzah/popen-noshell (warning: GPLv3), including the
    long discussion I had with the author in the issues
 
 I've yet to see a single bug report anywhere about vfork() not stopping all
 other parent threads causing an application to break.  Objectively speaking,
 without such a report, and without POSIX saying so (it does not! POSIX removed
 vfork()), NetBSD should not make that change!
 
 Nico
 --