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

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

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