← Back to context

Comment by cryptonector

4 years ago

> vfork() does the opposite of solving these problems. While there are a few functions that you can call after fork(), there is absolutely no function you can call after vfork() before exec(). You can't even write most local variables.

Mostly wrong.

You can call functions on the child side of vfork(), but you don't want to exec() in them -- you want to exec() in the same function that called vfork().

And you can write to local variables, but you have to be careful about it.

There's a ton of vfork()-using code that does these things.

Now, it's true that a compiler optimizer that knows nothing about vfork() but knows about _exit()'s semantics, could delete code it thinks is unreachable. So there is some issue, but you can just disable the optimizer if you run into this.

5 comments

cryptonector

Reply
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.

[0] https://man7.org/linux/man-pages/man2/vfork.2.html

  • cryptonector  4 years ago

    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.

    • int_19h  4 years ago

      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.

      1 reply →