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

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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

From: Joerg Sonnenberger <joerg%bec.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost, christos%netbsd.org@localhost
Subject: Re: kern/49017: vfork does not suspend all threads
Date: Thu, 6 Apr 2017 13:22:21 +0200

 On Thu, Apr 06, 2017 at 03:10:01AM +0000, Robert Elz wrote:
 >  There's no need to restrict vfork() children to async signal safe operations
 >  (the process limiting itself that way certainly won't hurt it, but it is
 >  not required) - it can do anything that the parent can do that affects only
 >  its internal (userland) state, or which affects purely the proc struct
 >  state in the kernel (so it can close files, or change the "close on exec"
 >  state, but not other file status flags).
 
 The problem is that many of the functions outside the "async signal
 safe" category are exactly allowed to such things. Anything using
 mutexes will not correctly work after vfork. That is an implementation
 restriction related to how NetBSD's libpthread work, but it is certainly
 not the only possible pitfall.
 
 I don't classify vfork in general as a hack -- it is a building block
 with a number of serious restrictions. Not working well with threads is
 just another one of those restrictions.
 
 Joerg