I sent revisions to the vfork() and fork() man pages to you months ago.
This controversial syscall was publically and vigorously debated on
the linux-kernel list in January of this year, prior to its inclusion
in the 2.2 kernels. See the archives.
The decision to implement was made with the blessing (and assistance) of
the keeper of the kernel himself. Considerations included performance,
conformance to published standards, existing implementations in Solaris,
HP-UX, Open/Free/NetBSD, etc, and porting of existing application code.
IMHO, creating manual pages which argue that a syscall is evil, broken
as designed, etc, is NOT appopriate. We have better forums for such
discussions.
If the vfork() syscall is evil then lets reopen the public discussion and
reach a decision to either accept it or pull it from the kernel entirely.
Otherwise, let the man pages document its semantics/behavior, along
with a warning that the porting issue cuts both ways.
Reed,
On Mon, Nov 01, 1999 at 02:26:26PM +0100, Andries.Brouwer@cwi.nl wrote:
> People tell me that vfork() no longer is equivalent to fork()
> as the manpage states. Unfortunately, they are right, so I
> wrote a new page - see below.
>
> I consider the introduction of vfork into Linux a very bad move
> (as will be clear from the text I wrote), but since there were
> people writing code and submitting patches there must be some
> positive side to this horrible kludge.
>
> If nobody corrects me, this will be the vfork man page in man-pages-1.27.
> (The title is borrowed from the BSD title:
> `vfork - spawn new process in a virtual memory-efficient way'
> )
>
> Andries - aeb@cwi.nl
>
> -------------------------------------------------------------------------
>
> VFORK(2) Linux Programmer's Manual VFORK(2)
>
>
> NAME
> vfork - create a child process in a broken way
>
> SYNOPSIS
> #include <unistd.h>
>
> pid_t vfork(void);
>
> POSIX DESCRIPTION
> The vfork() function has the same effect as fork(), except that
> the behaviour is undefined if the process created by vfork()
> either modifies any data other than a variable of type pid_t used
> to store the return value from vfork(), or returns from the func
> tion in which vfork() was called, or calls any other function
> before successfully calling _exit() or one of the exec family of
> functions.
>
> ERRORS
> EAGAIN Too many processes - try again.
>
> ENOMEM There is insufficient swap space for the new process.
>
> DESCRIPTION
> vfork, just like fork(2), creates a child process of the calling
> process. For details and return value and errors, see fork(2).
>
> Under Linux, fork() is implemented using copy-on-write pages, so
> the only penalty incurred by fork() is the time and memory
> required to duplicate the parent's page tables, and to create a
> unique task structure for the child. However, in the bad old days
> a fork() would require making a complete copy of the caller's data
> space, often needlessly, since usually immediately afterwards an
> exec() is done. Thus, for greater efficiency, BSD introduced the
> vfork system call, that did not fully copy the address space of
> the parent process, but borrowed the parent's memory and thread of
> control until a call to execve() or an exit occurred. The parent
> process was suspended while the child was using its resources.
> The use of vfork was tricky - for example, not modifying data in
> the parent process depended on knowing which variables are held in
> a register.
>
> BUGS
> It is rather unfortunate that Linux revived this spectre from the
> past. The BSD manpage states: "This system call will be elimi
> nated when proper system sharing mechanisms are implemented. Users
> should not depend on the memory sharing semantics of vfork as it
> will, in that case, be made synonymous to fork."
>
> Formally speaking, the POSIX description given above does not
> allow one to use vfork() since a following exec might fail, and
> then what happens is undefined.
>
> Details of the signal handling are obscure and differ between sys
> tems. The BSD manpage states: "To avoid a possible deadlock situ
> ation, processes that are children in the middle of a vfork are
> never sent SIGTTOU or SIGTTIN signals; rather, output or ioctls
> are allowed and input attempts result in an end-of-file indica
> tion."
>
> HISTORY
> The vfork() system call occurs in the BSD 2.9.1 (but not in the
> 2.8) manual pages. In Linux, it has been equivalent to fork()
> until 2.2.0-pre6 or so. Since 2.2.0-pre9 (on i386, somewhat later
> on other architectures) it is an independent system call. Support
> was added in glibc 2.0.112.
>
> CONFORMING TO
> The vfork call may be a bit similar to calls with the same name in
> other operating systems. They all resemble fork(), have obscure
> semantics, and are not really faster today than fork().
>
> SEE ALSO
> clone(2), execve(2), fork(2), wait(2)
>
>
> Linux 2.2.0 1 Nov 1999 1
>
> -
> 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/
-
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/