
A Fork() in the Road [pdf] - o_nate
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
======
wahern
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.

