Subject: Re: Real vfork() (was: third results)
To: None <tech-kern@NetBSD.ORG>
From: Greg A. Woods <woods@most.weird.com>
List: tech-kern
Date: 04/15/1998 21:26:12
[ On Wed, April 15, 1998 at 20:27:27 (+0200), Stefan Grefen wrote: ]
> Subject: Re: Real vfork() (was: third results) 
>
> > A forkexec() or spawn() solves the VM overcommit problem, but it becomes
> > much more complex if any file-descriptor fiddling or other special 
> > operations need to be done before the exec.
> 
> Yes and it is not portable. I think we shouldn't go he M$ way and
> make the API a moving target just because we think we can get a 
> (small) performance gain by having a special system call for every case.

Don't forget that the forkexec()/spawn() idea predates M$ by a long way
(they never invent anything! ;-), and we're not talking about using it
everywhere -- it would only be truely useful in places a real vfork() is
successful but not abused.  Also, it should easily be possible to
implement it as a wrapper function that would not require kernel
support, thus making it trivial to port, and more importantly maintain,
such applications that use it.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>