[lkml]   [1999]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: Porting vfork()
On Wed, Jan 06, 1999 at 08:28:55PM -0600, 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.


--- fork.2.bak Fri Jan 8 15:29:24 1999
+++ fork.2 Fri Jan 8 15:29:34 1999
@@ -66,7 +66,7 @@
.B fork
failed to allocate the necessary kernel structures because memory is tight.
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [W:0.134 / U:2.140 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site