5 ms·

Odd to not see any mention of vfork. vfork solves the problems with fork/exec for large programs.

remexre 4y ago
Isn't vfork much worse in terms of the problem the author is talking about, since the child can now acquire locks in the _parent's_ address space?
- stefan_ 4y ago
  I thought the point of vfork is that they do not share an address space. But there are other things still shared and they should really just have a CreateProcess.
  - remexre 4y ago
    no, fork creates a new address space, vfork doesn't the posix_spawn mentioned in the article is effectively the equivalent of CreateProcess
    - medoc 4y ago
      Last time I looked, posix_spawn() just called fork/exec
      - int_19h 4y ago
        That's an implementation detail at this point. The idea is to have a single syscall that takes all the information needed to spawn the process, and does so atomically, without the need to spread it across several calls. On Win32, that's CreateProcess(). On POSIX, the equivalent is posix_spawn().
      - cryptonector 4y ago
        In glibc it uses vfork() in some cases. In Solaris/Illumos it uses vfork() or vforkx(). In principle posix_spawn() can be a system call.
        comex 4y ago
        On macOS it is a system call.
  - monocasa 4y ago
    They still share an address space until exec replaces it for one of them. Particularly awful is that they share the same mutable stack which is a pathway that only leads to the inner circle of hell.
    - stefan_ 4y ago
      Assuming you call exec, of course. To not call exec after vfork is not an option; one of the many ways the fork family of functions are fundamentally broken.
      - monocasa 4y ago
        Well, without undefined behavior you can also call _exit(), continue within the same function, and receive conforming signals. Unfortunately this isn't always spelled out and there's code out there that definitely does other work invoking undefined behavior.
tsimionescu 4y 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. vfork() solves the problem of not wasting so much time on fork() when you're just going to call exec() afterwards (fork() does A LOT of work - potentially, anyway).
- cryptonector 4y 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.
  - tsimionescu 4y 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 https://man7.org/linux/man-pages/man2/vfork.2.html
    - cryptonector 4y 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.

Isn't vfork much worse in terms of the problem the author is talking about, since the child can now acquire locks in the _parent's_ address space?

stefan_ 4y ago
I thought the point of vfork is that they do not share an address space. But there are other things still shared and they should really just have a CreateProcess.
- remexre 4y ago
  no, fork creates a new address space, vfork doesn't the posix_spawn mentioned in the article is effectively the equivalent of CreateProcess
  - medoc 4y ago
    Last time I looked, posix_spawn() just called fork/exec
    - int_19h 4y ago
      That's an implementation detail at this point. The idea is to have a single syscall that takes all the information needed to spawn the process, and does so atomically, without the need to spread it across several calls. On Win32, that's CreateProcess(). On POSIX, the equivalent is posix_spawn().
    - cryptonector 4y ago
      In glibc it uses vfork() in some cases. In Solaris/Illumos it uses vfork() or vforkx(). In principle posix_spawn() can be a system call.
      - comex 4y ago
        On macOS it is a system call.
- monocasa 4y ago
  They still share an address space until exec replaces it for one of them. Particularly awful is that they share the same mutable stack which is a pathway that only leads to the inner circle of hell.
  - stefan_ 4y ago
    Assuming you call exec, of course. To not call exec after vfork is not an option; one of the many ways the fork family of functions are fundamentally broken.
    - monocasa 4y ago
      Well, without undefined behavior you can also call _exit(), continue within the same function, and receive conforming signals. Unfortunately this isn't always spelled out and there's code out there that definitely does other work invoking undefined behavior.

tsimionescu 4y 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. vfork() solves the problem of not wasting so much time on fork() when you're just going to call exec() afterwards (fork() does A LOT of work - potentially, anyway).

cryptonector 4y 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.
- tsimionescu 4y 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 https://man7.org/linux/man-pages/man2/vfork.2.html
  - cryptonector 4y 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.