Thus spake Bill Studenmund ("BS> ") sometime Yesterday...

BS>
BS> > | Again, I think this is the wrong approach. Instead of making vfork()
BS> > | work with SAs, we should consider avoiding vfork() in threaded
BS> > | programs and taking the hit of calling ordinary fork() instead.
BS> >
BS> > >Absolutely not. We should either not allow vfork() on threaded programs
BS> > >having it return SIGSYS, or make it work properly. Relying on threaded
BS> > >programs `knowing' that they should not call vfork() is a recipe for
BS> > >disaster. Finally, having vfork() work is easy enough...
BS> >
BS> > returning error on a syscall which has valid parameters sounds a bit
BS> > wierd.
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.

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.

I have a question (okay, two):

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

Can a thread create another thread?

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.

				--*greywolf;
--
Microshaft:  Where do you want to crash today?