In this section, we’ll talk about an aspect of OS design
that arguably needs to be revisited: the
fork() in the road.” Andrew Baumann, Jonathan Appavoo,
Orran Krieger, and Timothy Roscoe. In Proc. HotOS 2019.
The received wisdom suggests that Unix’s unusual combination of
exec()for process creation was an inspired design. In this paper, we argue that fork was a clever hack for machines and programs of the 1970s that has long outlived its usefulness and is now a liability. We catalog the ways in which fork is a terrible abstraction for the modern programmer to use, describe how it compromises OS implementations, and propose alternatives.
As the designers and implementers of operating systems, we should acknowledge that fork’s continued existence as a first-class OS primitive holds back systems research, and deprecate it. As educators, we should teach fork as a historical artifact, and not the first process creation mechanism students encounter.
As you read the paper, consider the following questions, and post a followup with your responses to the Ed announcement of section. At the latest, your responses are due one hour before section.
Question 1: The paper claims that
fork()is hard for commodity Unix-like OSes to implement. Is this claim true for the Singularity OS that we discussed in Lecture 16? In particular, what aspects of Singularity make
fork()easier or harder to implement than in a traditional Unix-like OS?
Question 2: The paper argues that a system call like
posix_spawn()is better than
fork(). Take a look at the man page for
posix_spawn(), and think about the semantics of the function. Do you think that, in the long term,
posix_spawn()will be able to avoid the complexity and efficiency problems that have beset
fork()? Why or why not?