Re: RFC: import of posix_spawn GSoC results

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 28 Dec, 2011, at 19:08 , 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.

But doesn't the parent need to know the same thing?  I'm having trouble
figuring out why the vfork() child thread in a multithreaded process would
have any constraints that were somehow different than the constraints you
generally need to observe when operating as a regular thread in a multithreaded
process.

It seems that if you vfork() in a threaded process the child fork could as
easily remember that it is operating in a threaded process as the parent
fork must.  If vfork() child fork is unsafe, why isn't the parent fork
equally unsafe, and why isn't this an argument that multithreaded programs in
general are unsafe?

Dennis Ferguson