Messages in this thread Patch in this message | | | Date | Fri, 8 Jan 1999 15:33:51 -0800 | From | Mark Jefferys <> | Subject | Re: 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/
| |