Re: RFC: import of posix_spawn GSoC results

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

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