[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.
can you explain how vfork is not thread safe?
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.
Main Index |
Thread Index |