Re: suggestion for improvement to vfork() man page

Hi,

On Thu, Jan 19, 2012 at 4:04 PM,  [off-list ref] 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html