On Thu, 11 Sep 2003, Kamal R Prasad 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.
>
> >Absolutely not. We should either not allow vfork() on threaded programs
> >having it return SIGSYS, or make it work properly. Relying on threaded
> >programs `knowing' that they should not call vfork() is a recipe for
> >disaster. Finally, having vfork() work is easy enough...
>
> returning error on a syscall which has valid parameters sounds a bit
> wierd.
> how difficult is it to introduce a new syscall that does the equivalent
> for vfork() + exec()?

Problem is no one would use it. The problem is there are things that need
to happen in the child between the {,v}fork() and the exec() call.

Also, the problem is that programs could be loading modules and libraries
that want to call vfork(), so just because the main program knew it was
threaded and should use such&such new call, the library/module probably
won't.

Take care,

Bill