[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: import of posix_spawn GSoC results
On Wed, 28 Dec 2011, Joerg Sonnenberger wrote:
> 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.
> Which is exactly why vfork usage is not safe. The child has to know all
> interfaces that are possible shared, which can often happen behind your
> back in libc.
Ahem. vfork() is dangerous because:
1) it can arbitrarily change the value of global data structures
2) it stomps on the parent's stack.
All threaded programs have problems with #1 which is why they have thread
safe libraries and locks. Or do locks not work after the vfork() call?
#2 is the same problem a non-threaded process has with vfork() and should
be solvable with the same mechanism.
Why would vfork() need to do anything fancy like suspend or clone any
other threads? Or am I missing something obvious?
Main Index |
Thread Index |