Decades ago, the BSD Unix developers came up with an efficient special case system call— the vfork(2). The idea at the time, was to perform some optimizations where you performed a fork and almost immediately an exec in the child (the fork-exec, in other words). As we know, using the fork-exec is quite a common and useful semantic (the shell and network servers use it heavily). When the vfork is called instead of the fork, the kernel does not go through the heavy copying operations usually required; it optimizes things.
The bottom line is this: At the time, vfork(2) was useful on Unix; but today's Linux fork(2) is as optimized as can be, rendering the vfork to the back door. It's still there, for perhaps two reasons: ...
