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: Mon, 10 Apr 2017 00:38:43 +0000

 Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
 >   |  Fork-safety issues are a necessary result of sharing state from a
 >   |  starting snapshot of it
 > 
 > But that kind of issue is the same whatever kind of fork() (with the
 > possible execption of the current vfork()) is used, there's nothing in
 > any of that which is peculiar to fork() over avfork() or perhaps even
 > lwp_create().
 
 vfork() has no fork-safety issues: the child must execve() or _exit(),
 and the restrictions on what functions in can call before then make it
 very difficult to do anything other than setup the execve().  The
 vfork() child certainly can't make any PKCS#11 function calls or what
 have you.
 
 avfork() would have the same execve()-or-_exit() requirement as
 vfork(), except _perhaps_ modified as "child-must-execve()-or-_exit()-
 OR-parent-must-_exit()".
 
 Any library code that calls getpid() to discover forks will be tripped
 though in the avfork() child, so I think we can't really make that
 relaxation.  But aside from that, if the parent _exit()s, then the
 avfork() child should be free from fork-safety concerns.
 
 >   |  Better then to have fork() than not, but even better to have vfork() to
 >   |  begin with.
 > 
 > I disagree with that, fork() is essential, vfork() is a nice optimisation
 > that is sometimes useful.
 
 posix_spawn()/_spawn()/CreateProcess() demonstrates that fork() isn't
 essential.  fork() was essential to speeding up development of shells by
 moving the spawning code into user-land -- that's my theory.
 
 >   |  That does not mean that they can't have made mistakes (e.g., the lack of
 >   |  a "create time" for files!),
 > 
 > You really don't want to get me started on that one ... "create time"
 > (aka the current birthtime in UFS2) is the greatest crock of sh*t of
 > all time.   I have never yet been able to find anyone who could explain
 > a use case for that nonsense that actually corresponds to anything that
 > has ever been implemented, or is even implementable.
 
 Really?  Maybe I'll ask you off-list.  I'm quite curious.
 
 >   |  Is this PR right place to do this?
 > 
 > No...
 
 Agreed.
 
 >   |  When main() returns, the program exits.
 >   |  When the callback function in pthread_create() returns, the thread
 >   |  exits.
 > 
 > That's not what we mean we we say the child of a vfork() cannot return,
 > what we mean is that it cannot unwind its stack, if one says the child
 
 Yes, but the reason it can't return is the shared stack.  avfork() would
 have no shared stack, therefore it wouldn't have that problem.
 
 > can return (as it can after fork()) then the two processes can continue
 > in parallel, each doing their own thing (as much as that makes sense to
 > the logic).  "You can return, but that means you exit" is not particularly
 > useful.
 
 It's what happens with: main() and pthread_create().  It's quite
 sensible.
 
 Nico
 --