Re: suggestion for improvement to vfork() man page

Hi,

On Fri, Jan 20, 2012 at 7:36 AM, Mike Frysinger [off-list ref] wrote:

On Wednesday 18 January 2012 22:16:28 starlight-Utvwg/EOxnhfq8cQ1yknNg@public.gmane.org wrote:

quoted

Also I don't think it is unfortunate (or a bug)
that vfork() continues to exist in Linux aside
from the fact that the semantics differ from
other *nixes in subtle and potentially
confusing ways.

As implemented in Linux vfork() is quite useful
and with the aforementioned clarifications to
the documentation, worth retaining.

Agreed. I inherited that text in the man page, but it never irritated
me quite *enough* to remove it. But all I needed was a little push.

it also most likely won't ever be going away.  a few reasons:
       - vfork() is really just a clone() with certain flags
       - clone() is never going away as it is used to create threads
       - vfork() is required for no-mmu systems (can't implement fork())
-mike

Thanks for those notes also Mike.

I've applied the patch below:

=====

--- a/man2/vfork.2
+++ b/man2/vfork.2

@@ -169,6 +169,40 @@ remaining blocked until the child either

terminates or calls
 and cannot rely on any specific behavior with respect to shared memory.
 .\" In AIXv3.1 vfork is equivalent to fork.
 .SH NOTES
+.PP
+Some consider the semantics of
+.BR vfork ()
+to be an architectural blemish, and the 4.2BSD man page stated:
+"This system call will be eliminated when proper system sharing mechanisms
+are implemented.
+Users should not depend on the memory sharing semantics of
+.BR vfork ()
+as it will, in that case, be made synonymous to
+.BR fork (2).\c
+"
+However, even though modern memory management hardware
+has decreased the performance difference between
+.BR fork ()
+and
+.BR vfork (2),
+there are various reasons why Linux and other systems have retained
+.BR vfork ():
+.IP * 3
+Some performance-critical applications require the small performance
+advantage conferred by
+.BR vfork ().
+.IP *
+.BR vfork (2)
+can be implemented on systems that lack a memory-management unit
+(typically, embedded systems), but
+.BR fork (2)
+can't be implemented on such systems.
+(However, on such systems,
+the preferred standard way of accomplishing the same result is to use
+.BR posix_spawn (3).)
+.\" http://stackoverflow.com/questions/4259629/what-is-the-difference-between-fork-and-vfork
+.\" http://developers.sun.com/solaris/articles/subprocess/subprocess.html
+.\" http://mailman.uclinux.org/pipermail/uclinux-dev/2009-April/000684.html
 .SS Linux Notes
 Fork handlers established using
 .BR pthread_atfork (3)

@@ -208,16 +242,7 @@ 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.
 .SH BUGS
-It is rather unfortunate that Linux revived this specter from the past.
-The BSD man page states:
-"This system call will be eliminated when proper system sharing mechanisms
-are implemented.
-Users should not depend on the memory sharing semantics of
-.BR vfork ()
-as it will, in that case, be made synonymous to
-.BR fork (2).\c
-"