hi, > On Tue, Dec 27, 2011 at 09:19:48AM +0000, YAMAMOTO Takashi wrote: >> vfork based implementation has its advantages. eg. less kernel code >> >> i'm not sure what kind of "dirty libpthread changes". >> can you explain? > > We would need to guarantee thread safeness of posix_spawn() - but vfork > itself is not. So either we would need to change the kernel vfork() to > be thread safe (I guess I could do that, but it would be an intrusive > mess), or deal with it inside libpthread somehow (I have no idea - > enumerate all threads and stop them?). > > But worst: I don't see how we could possibly gain the main benefit of > the interface (vfork like performance even for multithreaded apps) any > way if we go this route. > > Martin
can you explain how vfork is not thread safe? 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. YAMAMOTO Takashi