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>