On 28 Dec, 2011, at 19:08 , 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.
But doesn't the parent need to know the same thing? I'm having trouble figuring out why the vfork() child thread in a multithreaded process would have any constraints that were somehow different than the constraints you generally need to observe when operating as a regular thread in a multithreaded process. It seems that if you vfork() in a threaded process the child fork could as easily remember that it is operating in a threaded process as the parent fork must. If vfork() child fork is unsafe, why isn't the parent fork equally unsafe, and why isn't this an argument that multithreaded programs in general are unsafe? Dennis Ferguson
