3 ms·

Fork() Considered Harmful [pdf]

• bediger4000 7y ago
  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 7y ago
    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.