All true except they sort of beat around the bush regarding the fact that there exist no real alternatives. As they admit CreateProcess and pthread_spawn are also horrible interfaces: "It is infeasible for a single OS API to give complete control over the initial state of a new process."
The superior alternative is cross-process operations, which "yields the flexibility and orthogonality of the fork/exec model, without most of its drawbacks". However, it only exists in a couple of experimental operating systems and has never been tested in the real-world. There's a boatload of boilerplate library code that would invariably need to accompany such a primitive, and it's not at all clear that we'd end up in a substantially better position. I mean, technically speaking ptrace already permits such a design, but I don't see anybody clamoring to build that solution. Perhaps the people with the skills appreciate the pain the Cygwin developers dealt with, as it's basically how Cygwin emulated fork with the Win32 API.
There are many ways to improve the downsides of fork. For example, in Solaris' original thread design fork recreated all threads so there was never the async-safety issue. But we don't pursue these fixes. Why? Because it's good enough, and in particular flexible enough to allow for the emergence of things like containers without having to make a giant leap to an entirely new primitive.
1 comment
[ 3.6 ms ] story [ 10.3 ms ] threadThe superior alternative is cross-process operations, which "yields the flexibility and orthogonality of the fork/exec model, without most of its drawbacks". However, it only exists in a couple of experimental operating systems and has never been tested in the real-world. There's a boatload of boilerplate library code that would invariably need to accompany such a primitive, and it's not at all clear that we'd end up in a substantially better position. I mean, technically speaking ptrace already permits such a design, but I don't see anybody clamoring to build that solution. Perhaps the people with the skills appreciate the pain the Cygwin developers dealt with, as it's basically how Cygwin emulated fork with the Win32 API.
There are many ways to improve the downsides of fork. For example, in Solaris' original thread design fork recreated all threads so there was never the async-safety issue. But we don't pursue these fixes. Why? Because it's good enough, and in particular flexible enough to allow for the emergence of things like containers without having to make a giant leap to an entirely new primitive.