Section 5: Rethinking the process abstraction

In this section, we’ll talk about two ways to rethink processes in operating systems, inspired by two short papers.

The first paper argues that a foundational Unix abstraction, the fork system call, has held back operating system design and should be deprecated and removed.

The second paper describes a radically different modular operating system design in which an operating system is a process.


“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.

“Unikernels: The rise of the virtual library operating system.” Anil Madhavapeddy and David J. Scott. In Communications of the ACM, Jan. 2014.

What if all the software layers in a virtual appliance were compiled within the same safe, high-level language framework?

We present unikernels, a new approach to deploying cloud services via applications written in high-level source code. Unikernels are single-purpose appliances that are compile-time specialised into standalone kernels, and sealed against modification when deployed to a cloud platform. In return they offer significant reduction in image sizes, improved efficiency and security, and should reduce operational costs. Our Mirage prototype compiles OCaml code into unikernels that run on commodity clouds and offer an order of magnitude reduction in code size without significant performance penalty. The architecture combines static type-safety with a single address-space layout that can be made immutable via a hypervisor extension. Mirage contributes a suite of type-safe protocol libraries, and our results demonstrate that the hypervisor is a platform that overcomes the hardware compatibility issues that have made past library operating systems impractical to deploy in the real-world.

If you want more technical information on unikernels, read this optional, more technical article: “Unikernels: Library operating systems for the cloud” (Anil Madhavapeddy, Richard Mortier, Charalampos Rotsos, David Scott, Balraj Singh, Thomas Gazagnaire, Steven Smith, Steven Hand, and Jon Crowcroft, in Proc. ASPLOS 2013.)


Come to section with an idea for changing the process interface, however big or small.

Should the process interface be eliminated, à la unikernels? Should multiplexing of hardware resources happen at the virtual machine level? Should processes written in different programming languages inhabit different domains (so that statically-checkable domains can run faster, with fewer context switches)? Should fork be eliminated and replaced with a new system call, better than posix_spawn? Does new hardware (like GPUs) demand a new kind of process abstraction?

Post a note about your idea to the Ed announcement of section.