The POSIX specification for vfork() is a poor match for reality. Linux and NetBSD, and all good OSes, provide a vfork() that is actually useful. There have been

The POSIX specification for vfork() is a poor match for reality. Linux and NetBSD, and all good OSes, provide a vfork() that is actually useful. There have been some bad OSes that mapped it to fork(), just like there are bad OSes that restrict you to the portable character set (not even full ASCII) or that don't have coherency between mmap() and read(). Somewhere you must draw the line, or you'll spend forever trying to deal with obscure portability issues that are mostly theoretical. After a vfork(), the memory image is shared and the parent is prevented from running. The child is a fully separate process in all other ways. This special vfork state ends when the child does an exit or exec. This is how it works, no matter if POSIX wants to add weasel words or not. Even with the lame POSIX specification, the "executable you're execing into" is perfectly safe messing with file descriptors. Once that exec happens, the child becomes like any other. Systems with a proper vfork() are also safe before the exec. It certainly would be nice to have an interface similar to vfork that would take a function pointer and allocate a stack, optionally letting the parent continue on. Linux itself actually can support this, but glibc is uncooperative in exposing it.