3 ms·

You can do all of that stuff in a spawn model as well.

bluetomcat 4y ago
You can, but the interface of spawn(…) would grow enormous and complex. In the fork/exec model, you can execute arbitrary syscalls affecting the environment of the child, using all the inherited data from the parent.
- cesarb 4y ago
  There's a third possible API model, which is sort of between the spawn() model (everything for the new process configured in a single call) and the fork/exec model (the child process can run arbitrary code to set up the new process): the process creation API could create the new process in a "suspended" state (like CREATE_SUSPENDED does on Windows), the parent process could then manipulate the new process as desired, and finally tell the kernel to start it.
  - bluetomcat 4y ago
    The vfork syscall first appeared in BSD 3.0 and did it the other way around. When calling vfork, the parent is suspended until the child terminates or calls exec. The child is given read-only access to the parent's memory space, or it traps on an attempt to write. This is how they optimised it in the days before COW, by fully preserving the intended behavioural semantics of fork/exec. You shouldn't modify memory in the child and the OS therefore shouldn't copy the memory space.
- zozbot234 4y ago
  You could "spawn" a separate minimal binary that only has to set up the proper environment, then have that binary "exec" into the intended process.
  - bluetomcat 4y ago
    But that "minimal" binary would be a static and independent piece of code nevertheless. It wouldn't have access to the memory space of the parent so as to work with the already open descriptors without probing for them, it cannot use data already processed by the parent in the form of paths, etc. Essentially you run into the same problem - now the complexity of the spawn(...) interface is shifted to that binary.
    - zozbot234 4y ago
      > It wouldn't have access to the memory space of the parent so as to work with the already open descriptors without probing for them, it cannot use data already processed by the parent in the form of paths, etc. You could simply use ordinary IPC for these things, though. They need not be implemented as part of the OS.

You can, but the interface of spawn(…) would grow enormous and complex. In the fork/exec model, you can execute arbitrary syscalls affecting the environment of the child, using all the inherited data from the parent.

cesarb 4y ago
There's a third possible API model, which is sort of between the spawn() model (everything for the new process configured in a single call) and the fork/exec model (the child process can run arbitrary code to set up the new process): the process creation API could create the new process in a "suspended" state (like CREATE_SUSPENDED does on Windows), the parent process could then manipulate the new process as desired, and finally tell the kernel to start it.
- bluetomcat 4y ago
  The vfork syscall first appeared in BSD 3.0 and did it the other way around. When calling vfork, the parent is suspended until the child terminates or calls exec. The child is given read-only access to the parent's memory space, or it traps on an attempt to write. This is how they optimised it in the days before COW, by fully preserving the intended behavioural semantics of fork/exec. You shouldn't modify memory in the child and the OS therefore shouldn't copy the memory space.
zozbot234 4y ago
You could "spawn" a separate minimal binary that only has to set up the proper environment, then have that binary "exec" into the intended process.
- bluetomcat 4y ago
  But that "minimal" binary would be a static and independent piece of code nevertheless. It wouldn't have access to the memory space of the parent so as to work with the already open descriptors without probing for them, it cannot use data already processed by the parent in the form of paths, etc. Essentially you run into the same problem - now the complexity of the spawn(...) interface is shifted to that binary.
  - zozbot234 4y ago
    > It wouldn't have access to the memory space of the parent so as to work with the already open descriptors without probing for them, it cannot use data already processed by the parent in the form of paths, etc. You could simply use ordinary IPC for these things, though. They need not be implemented as part of the OS.