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