Mo Libden [m0lib...@mail.ru] wrote:
> 
> now this is intriguing.
> AFAIK, classical vfork was invented in earlier BSD to avoid expensive
> duplication of a parent process in case all the child does is launch of
> other executable. SysV solved it with CoW, BSD came up with vfork.
> 
> Now, how come OpenBSD has vfork which does not work as the classic
> vfork, instead we can use rfork, which does what vfork is supposed to do?

rfork is the spork of forks. vfork, not so much.

vfork(2)

     vfork() was originally used to create new processes without fully copying
     the address space of the old process, which is horrendously inefficient
     in a paged environment.  It was useful when the purpose of fork(2) would
     have been to create a new system context for an execve(2).  Since fork(2)
     is now efficient, even in the above case, the need for vfork() has
     diminished.  vfork() differs from fork(2) in that the parent is suspended
     until the child makes a call to execve(2) or an exit (either by a call to
     _exit(2) or abnormally).  In addition, fork handlers established using
     pthread_atfork(3) are not called when a multithreaded program calls
     vfork().

rfork(2)

     The fork functions (fork(2), vfork(2), and rfork()) create new processes.
     The new process (child process) is an exact copy of the calling process
     (parent process), except as outlined in the fork(2) manual page.  rfork()
     is used to manipulate the resources of the parent process and the child
     process.

     Operations currently supported include whether to copy or share the file
     descriptor table between the two processes, whether to share the address
     space, and whether the parent should wait(2) for the child process to
     _exit(2).  rfork() takes a single argument, flags, which controls which
     of these resources should be manipulated.  They are defined in the header
     file <sys/param.h> and are the logical OR of one or more of the
     following:

     RFFDG     Copy the parent's file descriptor table.  If this flag is
               unset, the parent and child will share the parent's file
               descriptor table.  Descriptors will remain in existence until
               they are closed by all child processes using the table copies
               as well as by the parent process.  May not be used in
               conjunction with RFCFDG.

     RFPROC    Create a new process.  The current implementation requires this
               flag to always be set.

     RFMEM     Force sharing of the entire address space between the parent
               and child processes.  The child will then inherit all the
               shared segments the parent process owns.  Subsequent forks by
               the parent will then propagate the shared data and BSS segments
               among children.

     RFNOWAIT  Child processes will have their resources reaped immediately
               and implicitly when they terminate instead of turning into
               zombies, so the parent process may not call wait(2) to collect
               their exit statuses and have their resources released
               explicitly.

     RFCFDG    Zero the child's file descriptor table (i.e. start with a blank
               file descriptor table).  May not be used in conjunction with
               RFFDG.

     RFTHREAD  Create a kernel thread in the current process instead of a
               separate process.  Must be combined with RFMEM.  Automatically
               enables RFNOWAIT.  The kern.rthreads sysctl must be enabled for
               this to succeed.

     fork(2) can be implemented as a call to rfork() using "RFFDG|RFPROC", but
     isn't for backwards compatibility.  If a process has file descriptor
     table sharing active, setuid or setgid programs will not execve(2) with
     extra privileges.

Reply via email to