Section 5: Rethinking OS Abstractions

In this section, we’ll talk about an aspect of OS design that arguably needs to be revisited: the fork() abstraction.

Required reading

“A 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 fork() and 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.

Preparation

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?