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.

> The thing I think we need to look at is that, realistically, threading
> is a superset of what a vfork() accomplishes, at least at my first glance.

Not really. vfork() is a fork() shortcut for when you want to create a
new process. Sometimes, even in a threaded program, you really want a
new process (a different protection domain, different application
code, etc.) rather than a new thread.

> 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().

> Can a thread create another thread?

I'm not sure what circumstances you're asking about. In an ordinary
threaded process, any thread can call pthread_create() and create
another thread; there's no restriction, for example, that only the
"first" thread create others. However, if you're referring to the
fork()-in-a-threaded-app situation, one of the restrictions on the
child process is that it can not make any pthread_* calls until after
the exec() has occurred (at which point it's free to do everything).

> 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().

        - Nathan