christos@zoulas.com (Christos Zoulas)
Sent by: tech-kern-owner@NetBSD.org
09/10/2003 08:54 PM
 
        To:     "Nathan J. Williams" <nathanw@wasabisystems.com>
        cc:     tech-kern@NetBSD.org
        Subject:        Re: popen reentrant (was Re: SA/pthread and vfork)

 

On Sep 10,  1:38pm, nathanw@wasabisystems.com ("Nathan J. Williams") 
wrote:
-- Subject: Re: popen reentrant (was Re: SA/pthread and vfork)

| > It seems to me that the vfork semantics should be changed so that 
upcalls
| > should not be happening while the child is running on the parent's 
stack.
| > Maybe we should introduce a process flag that indicates P_INVFORK, and
| > have execve clear it. While a process is in P_INVFORK, it cannot 
execute
| > upcalls.
| 
| 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()? 

regards
-kamal