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

[christos%zoulas.com@localhost (Christos Zoulas)]

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

From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/49017: vfork does not suspend all threads
Date: Wed, 5 Apr 2017 16:38:32 -0400

 On Apr 5,  7:35pm, n54%gmx.com@localhost (Kamil Rytarowski) wrote:
 -- Subject: Re: kern/49017: vfork does not suspend all threads
 
 |  Well vfork(2) is supposed to suspend a parent process.
 |  "The parent process is suspended while the child is using its resources."
 |  
 |   -- vfork(2)
 |  
 |  It's out of POSIX so it's rather harsh to dictate behavior change.
 
 This wording predates threads and it is not specified in ToG:
 
 http://pubs.opengroup.org/onlinepubs/009695399/functions/vfork.html
 
 I.e. the suspension of the parent is historical behavior mandated by
 implementation convience; it would be difficult to make anything working
 reliably if the parent was altering the stack frame the child is currently
 executing.
 
 |  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.
 
 Well, they are not regular processes; linux just does not differentiate
 between threads and processes by re-using the proc structure to describe
 both. In both implementations they end up sharing vmspace, file descriptors,
 etc.
 
 |  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. No matter what the
 |  original syscall or API was used (clone(2), __clone(2), posix_spwan(2),
 |  fork(2)...).
 
 That is orthogonal; in fork() the parent is not suspended and ptrace has
 no problem with that. In vfork() only the thread executing vfork() is,
 and again ptrace has no problem with that. The semantics if the other
 threads should be suspended is the question here. Nico claims that it
 is not harmful if they are, and it is actually beneficial. I have come
 to the realization that this is true if the child is careful not to
 alter the parent data (which has been always the case). The question is:
 
     Can the other threads harm the child or the parent while it is vfork()ing?
 
 I can't think of a way.
 
 |  I thing you might be interested in designing something like _lwp_vfork().=
 
 How does this solve the problem? What does _lwp_vfork() fork? Does it create
 a new thread? In what process context?
 
 christos