Hi, On Thu, Jan 19, 2012 at 4:04 PM, <starlight@xxxxxxxxxxx> wrote: > Hello, > > Please consider the following two suggestions for > adjusting the vfork() man page. > > In the "Linux Description" section it should be > mentioned that vfork() does not suspend all the > threads in the parent process and only suspends > the thread issuing the call to vfork(). The > wording is misleading and I misunderstood the > semantics for a long time, thinking that all > threads would be suspended. Had to test it to > determine the actual effect for certain. In our > case suspending all threads for even a few > microseconds is unacceptable. Good point. For 3.36, I made the following change. ===== --- a/man2/vfork.2 +++ b/man2/vfork.2 @@ -97,7 +97,7 @@ where a child is created which then immediately issues an .BR vfork () differs from .BR fork (2) -in that the parent is suspended until the child terminates +in that the calling thread is suspended until the child terminates (either normally, by calling .BR _exit (2), ===== > Also, it is important to note that the > clone(CLONE_VFORK|CLONE_VM) call invoked by > vfork() makes a separate copy of all process > resources except the address space. While this is > implied by the statement "the vfork() function has > the same effect as fork(2)," this is easily > overlooked by someone who works with various UNIXs > where this is most definitely not the case. I'm just curious here... The most pertinent case I can think of here is file descriptors, which *are* duplicated on all vfork() implementations that I've come across. When you say "UNIXs where this is most definitely not the case", what (process attributes) are you thinking of. > This matters for situations like ours where a > process with a huge address space, real-time > priority and root privileges must occasionally > spawn scripts that should run at user priority > with user privileges. Using fork() is expensive > due to the cost of replicating very large page > tables and vfork() is an excellent alternative. > But the subtle difference between Solaris/AIX and > Linux caused us to unnecessarily disable the code > that lowers priority and surrenders root > permission before issuing the exec() call to run > scripts. Yes, a few words on those lines does not hurt. I made the following change: ===== --- a/man2/vfork.2 +++ b/man2/vfork.2 @@ -110,9 +110,19 @@ The child must not return from the current function or call .BR exit (3), but may call .BR _exit (2). -.PP -Signal handlers are inherited, but not shared. -Signals to the parent + +As with +.BR fork (2), +the child process created by +.BR vfork () +inherits copies of various of the caller's process attributes +(e.g., file descriptors, signal dispositions, and current working directory); +the +.BR vfork () +call differs only in the treatment of the virtual address space, +as described above. + +Signals sent to the parent arrive after the child releases the parent's memory (i.e., after the child terminates or calls ===== 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
