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.
I'm confused - exactly due to the above, I don't see how it is possible to use vfork() in a multithreaded application safely. Don't other parent threads touching arbitrary memory violate the basic vfork assumption of a fixed shared VM state untill child does the exec? If not, I don't see the need for posix_spawn() at all (besides interface simplicity, but a libarary wrapper would do, as you say). Martin
