Comment by tsimionescu
4 years ago
That's all undefined behavior, under POSIX at least [0]:
> The vfork() function has the same effect as fork(2), except that the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit(2) or one of the exec(3) family of functions.
So sure - you can do these things, but they have very little defined semantics after vfork().
It is true that Linux describes the semantics more clearly, so perhaps on Linux it is safer to use.
If you can call _exit() and exec, then you can call other functions too. I do believe that the Open Group has changed the description of vfork() to discourage its use because of an old and incorrect paper from the 80s. Actual implementations of vfork() are not as dangerous as the Open Group text purports them to be.
Moreover, most posix_spawn() implementations use vfork(), and they call more functions than _exit() and exec on the child side.
Let's be reasonable about these things.
An implementation of posix_spawn() is usually owned by the same people who implemented vfork(), so they know what is and isn't safe to call in that particular implementation. But we don't, and we shouldn't assume that the implementation will not change. That's exactly why public APIs and stability guarantees exist.
Not on Linux!
Even if that's true, doing so after vfork() is still much harder than after fork(), not easier.