tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: RFC: import of posix_spawn GSoC results


> 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.


Home | Main Index | Thread Index | Old Index