Greywolf <greywolf@starwolf.com> writes:

> BS> > how difficult is it to introduce a new syscall that does the 
equivalent
> BS> > for vfork() + exec()?
> 
> Funny, I was asking myself that same question yesterday.

>"posix_spawn()" is the interface you're looking for, possibly. It's
>somewhat contentious, mostly because it's recognized that it's not
>really as powerful as [v]fork()+exec() in terms of environment and
>file descriptor manipulation in the child, although it tries to cover
>the common cases.

If the code between a vfork() and an exec() is (guaranteed to be) minimal, 
then it should be possible to set a flag inside the kernel when vfork() is 
called, and then when exec() is called, execute the code for posix_spawn() 
instead.
 

> If a process threads itself into, say, four threads, can a thread
> fork()/exec() without destroying the parent?

>Yes. The fork() call is specified (and standardized) in a
>multithreaded process to only have one thread in the child; that
>thread in the child can do a few things and then exec().

Is this because threads came into existence later on?


> Unless I'm mistaken, vfork() came into being because threading didn't
> exist at the time.  Had threading been around, I doubt vfork() would 
ever
> have been written.

>Doubtful. Again, vfork() is a shortcut for the fork()+exec() path, not
>a way to provide concurrency - it's actually less useful for
>concurrency than plain old fork().

It came into being because memory was precious a few decades back and the 
only way to provide concurrency was to fork()+exec() which would mean 
copying a lot of pages unnecssarily [depending on how pro-active the VM 
was]. vfork() is in a way unnecessary right now.

regards
-kamal