[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/49017: vfork does not suspend all threads
The following reply was made to PR kern/49017; it has been noted by GNATS.
From: Nico Williams <Nico.Williams%twosigma.com@localhost>
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.
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!
Main Index |
Thread Index |