Using vfork() -vs fork()

[Guy Harris]

>Pertaining to vfork() and fork() usage in Berkely-specific C programs:
>
>From what I can glean from the manual, the advantages of vfork() over
>fork() are (1) virtual memory efficiency and (2) shared access to parent
>memory, data structures, etc.  until an execv().

Uhh, 2) isn't supposed to be thought of as an advantage - it's supposed
to be thought of as a consequence of the current implementation, subject
to change at any time.  I.e., don't *rely* on this behavior, for, as the
vfork man page says:

     BUGS
	This system call will be eliminated when proper system sharing
	mechanisms are implemented.  Users should not depend on the memory
	sharing semantics of "vfork" as it will, in that case, be made
	synonymous to "fork".

>The disadvantage seems to be that returning to the parent context while
>the childs context still exists does not work.  Does this mean that
>spawning an asynchronous process via vfork() is not possible?

Unless the asynchronous process is going to be running a different
program - i.e., it's going to do an "exec" - yes.  "vfork" was
specifically intended to be used when the subprocess was going to do a
few things - things like shuffle file descriptors, change current
directory, etc. - and then "exec".  None of those things should modify
any global data structures whatsoever, except for those in the kernel/U
area....

>My application wants to spawn children to:
>(1) execute adhoc subtasks (like `system("command")' ).
>(2) execute adhoc subtasks asynchronously (like `system("command &")' ).
>(3) execute cooperative subtasks for data sharing (like `popen("command")' ).
>
>My feeling is that vfork() is less appropo for this application than
>fork().  Am I offbase about this?

If in the "like ..." examples you mean the child process really will do
the equivalent of that - which means doing an "exec" of the program in
question - "vfork()" is appropriate.  If you mean that the child will be
running the *same* code as the parent - and not simply by virtue of
doing an "exec" of the same program - "vfork()" is completely
inappropriate.

>Can someone provide concrete examples of where I'd want to use vfork(),
>rather than fork()?

1) The "system()" library routine could use it, since it just "exec"s
   "/bin/sh" after the "vfork()".  (In fact, in 4.xBSD, it *does* use
   "vfork()".)

2) The "popen()" library routine could use it, since it just shuffles
   file descriptors and "exec"s "/bin/sh".  (In fact, in 4.xBSD, it
   *does* use "vfork()".)

3) Shells can often use it, since they shuffle file descriptors, etc.
   and then "exec" the command.  If the command is a script in their own
   language, though, and they're going to execute the script by e.g.
   jumping back to their main command-interpretation loop (which is
   basically what the Bourne shell does if the "exec" fails with ENOEXEC
   - if the file has a "#!" line, the "exec" succeeds because it fires
   up a new "/bin/sh"), they can't use it, though, since the child
   process will still be running the same program.

4) "make" can use it, since it just "exec"s the program or "/bin/sh".

5) Etc..