Hi, On Fri, Jan 20, 2012 at 7:36 AM, Mike Frysinger <vapier@xxxxxxxxxx> wrote: > On Wednesday 18 January 2012 22:16:28 starlight@xxxxxxxxxxx wrote: >> 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 -" - +.PP Details of the signal handling are obscure and differ between systems. The BSD man page states: "To avoid a possible deadlock situation, processes that are children ==== Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
