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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/49017: vfork does not suspend all threads
Date: Sat, 08 Apr 2017 22:19:36 +0700

     Date:        Fri,  7 Apr 2017 20:40:01 +0000 (UTC)
     From:        Nico Williams <Nico.Williams%twosigma.com@localhost>
     Message-ID:  <20170407204001.1F0147A2B8%mollari.NetBSD.org@localhost>
 
   |  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().
 
   |  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.
 
   |  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.
 
 That is it is easy to explain what would be useful for a create time,
 but no-one has ever implemented it in a way that those uses work, and
 it is probably impossible (since much of what is actually desired depends
 on intangibles of what is going on inside the user's head.)   On the other
 hand, as the current UFS2 illustrates, implementing something called
 a birthtime (or create time) is easy, it just doesn't correspond to
 anything actually useful in practice (which is why it is the most
 underused filesystem feature of all - probably the least used feature of
 the whole system, including the exotic stuff.)
 
   |  Is this PR right place to do this?
 
 No...
 
 
   |  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
 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.
 
 kre