Re: RFC: import of posix_spawn GSoC results

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Wed, 28 Dec 2011, Joerg Sonnenberger wrote:

> On Wed, Dec 28, 2011 at 04:07:45AM +0000, YAMAMOTO Takashi wrote:
> > my understanding:
> > there is no need to stop other threads as far as posix_spawn is concerned.
> > so there is no big performace problems with a vfork-based implementation.
> > because our current implementation of vfork suspends the calling threads
> > only, it can be used to implement posix_spawn as it is.  a vfork'ed child
> > should carefully avoid touching memory shared with other threads, but it's
> > doable and not too complex.
> 
> Which is exactly why vfork usage is not safe. The child has to know all
> interfaces that are possible shared, which can often happen behind your
> back in libc.

Ahem.  vfork() is dangerous because:

1) it can arbitrarily change the value of global data structures

2) it stomps on the parent's stack.

All threaded programs have problems with #1 which is why they have thread 
safe libraries and locks.  Or do locks not work after the vfork() call?

#2 is the same problem a non-threaded process has with vfork() and should 
be solvable with the same mechanism.

Why would vfork() need to do anything fancy like suspend or clone any 
other threads?  Or am I missing something obvious?

Eduardo