At 12:04 PM 2/8/2012 +1300, Michael Kerrisk wrote: >Hi, > >On Wed, Feb 8, 2012 at 10:50 AM, <starlight@xxxxxxxxxxx> wrote: >> +(However, on such systems, >> +the preferred standard way of accomplishing the same result is to use >> +.BR posix_spawn (3).) >> >> I'm not sure I agree on this. Linux posix_spawn() >> calls fork() > >I think isn't quite correct. I believe glibc's posix_spawn uses >vfork() where it can. See sysdeps/posix/spawni.c::spawni(). Looked at glibc-2.9 and posix_spawn() uses fork() in only when no process attibutes are modified (i.e. it respects the AIX and Solaris semantics of vfork though this is a bit irrelevent since AIX and Solaris have kernel-native support for posix_spawn) or when a non-standard POSIX_SPAWN_USEVFORK flag is present. It's rather muddy so I stick with #ifdef vfork() for Linux and #ifdef posix_spawn() for the *nixes. > >So, I'll change that last sentence to > >[[ >(POSIX.1-2008 removed vfork() from the standard; the POSIX rationale >for the posix_spawn(3) function notes that that function, which >provides functionality equivalent to fork(2)+exec(3) is designed >to be implementable on systems that lack an MMU.) >]] > >What do you think? That's fair. Perhaps the posix_spawn() page should have some text regarding the conditional use of vfork() under the covers. I seen no mention of vfork() on the die.net page, and can't find it on kernel.org. -- 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
