On Wed, Sep 10, 2003 at 10:41:49PM -0700, Bill Studenmund wrote:
> On 10 Sep 2003, Nathan J. Williams wrote:
> 
> > Again, I think this is the wrong approach. Instead of making vfork()
> > work with SAs, we should consider avoiding vfork() in threaded
> > programs and taking the hit of calling ordinary fork() instead.
> 
> Would it be legal to implement vfork() for a threaded app as a fork +
> implicit wait in the parent thread for the child to exit? Those semantics
> would be easy to implement in a threaded app context, and would have
> reasonable semantics to let other threads keep going.

The advantage of vfork() over fork() is that unlike fork(), vfork() 
does not increase a process' memory commitments.  If we ever start
tracking memory committments there will be many instances where a
process can vfork()+exec() but not fork()+exec().

OTOH, for a threaded process the entire fork()+exec() model is
obsolescent.  We should be able to change that to the equivalent
of pthread_create()+exec() if it weren't for the whole file
descriptor manipulation thing.

Eduardo