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:01:56 +0000

 Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
 > It appears to me as if the discussion on this has largely divided
 > along traditional lines - those who (fundamentally) believe that
 > vfork() is an evil hack, and should be removed (ideally) but in the
 
 Well, no one seems to have said that, though several seem wedded to
 pre-threaded-model text about stopping the parent process and then extending it
 to the threaded model in the obvious, but horrible way.
 
 > meantime restricted in all ways possible to limit its use, so that
 > hopefully it can go away some day not too far away - and those who
 > believe vfork() is a valuable tool, which should be exploited in
 > all ways possible, and enhanced where practical to make it even more
 > useful.
 
 I'll take it much further: it is fork() that is EVIL, and vfork() that is GOOD.
 
 Here's my rationale for such an extraordinary statement:
 
 https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234
 
 Briefly: fork()'s copying and/or COW are terrible and would never have been
 necessary had Dennis Ritchie et. al. thought of vfork()'s semantics.  In the
 beginning processes were so small that fork()'s copying was not obviously a
 horrible feature.  Besides, fork() has a ton of safety issues (which I mostly
 did not address in that gist, but I could and will) that make vfork() look like
 not so bad.  Anyone who says that vfork() is impossibly hard to use correctly
 without pointing out that fork() is in some ways harder still to use
 correctly... just hasn't had the misfortune of having to fix fork-safety
 problems in real-life, production code (I have).
 
 Now, vfork() is... clumsy because of the stack sharing silliness, but it
 predates threads, so its authors probably did not realize that taking a
 callback function and argument to run in a new stack would have been a superior
 design -- I forgive them this oversight because vfork() is nonetheless awesome
 goodness, and all the more so if it doesn't stop all other threads in the
 parent process.
 
 I didn't always think this way.
 
 I used to think: "haha, look at CreateProcess() on Windows, what a disaster,
 how terribly hard it is to use, and all because they had the elegance of
 fork()+exec()".  But that was wrong.  fork() is inelegant.  Whereas vfork()+
 exec() is quite elegant.
 
 Nico
 --