lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Porting vfork()
Date
From
> On Tue, Jan 05, 1999 at 03:46:11PM -0600, kernel@draper.net wrote:
> > So, the question: is linux vfork() behavior annoying anyone else and is it
> > worth fixing? (other than to eliminate its appearance in the BUG area of the
> > Linux fork() man page ;)
>
> What are you doing with vfork? The reason vfork exists is in the special
> case where fork() is followed by exec*(), and the memory copy (used to be?)
> prohibitively expensive. [I am missing a reference to this effect, so I
> can't be 100% authoritative. Reportedly, _The Magic Garden Explained_
> talks about this, but I am passing this along secondhand]
>


Did older VM machines not enable copy-on-write, making vfork crucial?

I've never come across a real-world example of where vfork couldn't be simply
aliased to fork().

Is there anything that MUST use vfork (i.e. could rewriting the code eliminate
the vfork, replacing it with fork?)

Since I've been using Unix (15+ years), the only rational I've heard for using
vfork is "its faster"...most programmers don't know or care about the special
semantics...


Marty Leisner





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [from the cache]
©2003-2011 Jasper Spaans