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: Wed, 5 Apr 2017 20:45:53 +0000

 On Wed, Apr 05, 2017 at 06:42:25PM +0000, Nico Williams wrote:
 > Please do NOT stop any threads in the vfork() parent other than the one that
 > called vfork().  Also, allow me to make an argument for this.
 > 
 > First, I suppose I should look at rationales for stopping all threads in a
 > vfork() parent.  [...]
 
 Let me respond to each response so far:
 
 Martin Husemann <martin%duskware.de@localhost> wrote:
 > At leaset in NetBSD posix_spawn() is completely unrelated to vfork().
 > Noone is suggesting to stop any thread in a process doing posix_spawn().
 
 I'm glad that's the case (it seems posix_spawn() is a system call in NetBSD).
 
 The only relevance of this to vfork() is that you could obsolete it (but
 probably not remove it for a long time yet), but then why make any changes to
 vfork()?  Are there applications that are breaking that couldn't be fixed in
 some other way?
 
 (ISTR Thor telling me that the kernel-coded posix_spawn() reduced performance
 and that it was removed.  It seems I remembered half-correctly.  He did tell me
 that the kernel implementation is slower than the user-land implementation.)
 
 > Using vfork() in a program with multiple active threads is madness,
 > posix_spawn() is the only sensible way.
 
 Such a statement requires explanation.  I was careful to provide explanation
 for my possibly-extraordinary-seeming statements about this.
 
 Kamil Rytarowski wrote:
 > Well vfork(2) is supposed to suspend a parent process.
 > 
 > "The parent process is suspended while the child is using its resources."=
 
 I addressed this very specifically.  I believe it's incorrect to say that
 because vfork() absolutely must stop the parent thread that called it, and
 because the man page said so without referring to threads because it long
 predated threads, that it must mean "stop all parent threads" now that we have
 threads.
 
 Please recall that an incorrect "vfork() is harmful" meme caused it to be
 removed (broken, actually) in 4.4BSD, and later to be re-added in all
 subsequent BSDs.  Cargo culting "stops the parent process" now is just that.
 
 > It's out of POSIX so it's rather harsh to dictate behavior change.
 
 How is it harsh?  It's out of POSIX -- that means you're _free_ to change it.
 
 Moreover, since some OSes don't stop all threads in the parent (e.g., Linux and
 NetBSD), one perfectly legitimate thing to do at the Open Group would be to
 seek to modify the specification to allow it, if POSIX still specified it at
 all.  Participants do this all the time.  And even POSIX never said that
 vfork() stops all threads in the parent process -- it merely cargo copied the
 original text from BSD and then added a scary warning that one must never use
 vfork(), as if fork() were somehow trivial to use safely (it is not).
 
 > Also going for your proposal is imho violating thread-process model in
 > NetBSD. It's Linux concept to emulate threads with clone(2), while they
 > are still regular processes.
 
 The only way to make sense of this statement is that you're taking text from
 the pre-threads vfork() man page about stopping the parent process and
 interpreting that in terms of the threaded process model.  But that's WRONG.
 The pre-threads vfork() man page is pre-threaded process model.  In a threaded
 world it is perfectly sensible to revisit that text rather than cargo cult it.
 
 > In ptrace(2) we have two interfaces: PTRACE_FORK and PTRACE_VFORK. The
 > difference between them is only in the point whether the parent process
 > (with all threads) has been suspended or not. [...]
 
 How does that force vfork() (when not being ptrace'd) to also stop all threads
 in the parent??  I don't follow.
 
 Thanks,
 
 Nico
 --