
Fork() Considered Harmful [pdf] - asimpletune
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
======
bediger4000
Finally, an interesting paper on why fork() isn't so great. There've been many
of these over they years, most of them incoherent.

Unfortunately, this is also one of those "X is bad" things, for an important X
(creating new processes) that doesn't offer an alternative. I quote: "in our
opinion, most uses of fork andexec would be best served by a spawn API." The
authors do not go on to offer specifics. The best CS minds of the last 30
years have often said the same thing, but when pressed, offer a "spawn" that
doesn't really do all that much, is flag-heavy, and causes some use cases to
be difficult or impossible.

I'm going to have to write this paper off as just another rant about fork().

~~~
asimpletune
I didn’t take that at all from the paper. I think they’ve provided valid
reasons for fork bring harmful, which is that the original spec required that
the child process is exactly the same as the parent in all ways modulo its
pid, and that this became bad due to the “all ways” qualifier. However, I
think the difficulty in having better alternative is addressed in the paper.
They suggest relaxing the “in all ways” requirement as a key to a replacement.
In that context, the caller would have to understand what exactly they need
behind the spawning, which makes sense. So I think they’re encouraging systems
developers to a.) use these existing alternatives so that b.) we can deprecate
the too coursely grained fork() and eventually c.) remove it usage entirely
with some future breaking change. C seems like a pipe dream, but i think they
argue quite clearly that A is actually already happening. Maybe B will come up
not too long in the distant future.

