lkml.org 
[lkml]   [1999]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: Porting vfork()
On Wed, Jan 06, 1999 at 08:28:55PM -0600, kernel@draper.net wrote:

% In a proper vfork() implementation, the child shares its parent's address space
% (and usurps the parents thread of control) until a call to execve (or exit)
% is made. Note that the parent is suspended until the child calls execve
% or exit.

% My intent in this thread was to gage the vfork() impact. It makes no sense
% to commit time developing a kernel solution if only a very few applications
% have such silly dependencies.

It should also be noted that the Unix98 standard specifically allows
vfork() to act just like fork():

"On some systems, vfork() is the same as fork()."

(It defines vfork() as a fork() that has undefined behavior if misused.)

Personally, I'd say that any program that relies on vfork() acting
differently is broken. Patch attached.


Mark


--- fork.2.bak Fri Jan 8 15:29:24 1999
+++ fork.2 Fri Jan 8 15:29:34 1999
@@ -66,7 +66,7 @@
.B ENOMEM
.B fork
failed to allocate the necessary kernel structures because memory is tight.
-.SH BUGS
+.SH NOTES
Under Linux,
.B vfork
is merely an alias for

-
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    [W:0.109 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site