On Wednesday, September 10, 2003, at 11:17 PM, Bill Studenmund wrote:

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

Isn't the simple solution, for pthreads, just equate __vfork = _sys_fork
in libpthread.  Any use of vfork(2) should be able to be replaced by 
fork(2)
with no change in behavior.   The sharing of address space is an
optimization, not a communications mechanism.  Any applications that
breaks is broken and needs to be fixed.
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: 
http://3am-software.com/bio/matt/ Cupertino, CA              
disclaimer: I avow all knowledge of this message.