A fork() in the road

Timothy Roscoe, 20 April 2019

Andrew Baumann, Jonathan Appavoo, Orran Krieger, and I have written a paper for Hot Topics in Operating Systems next month about the Unix fork() system call.

fork() is roughly as old as I am - it was in the original version of Unix - so it seems a bit odd to regard it as a “hot topic”. In the paper we argue that today it should be deprecated, for a variety of reasons.

All four of us have been fascinated by fork() for a long time. We’ve been involved in building various operating systems in industry and academia for many years - including L4 (Andrew), Nemesis (Mothy), Mungi (Andrew), Tornado (Orran, Jonathan), K42 (Orran, Jonathan, Andrew), Barrelfish (Andrew, Mothy), and Drawbridge (Andrew) - none of which really supported fork() well, either by accident or design. This was our attempt to get our collective thoughts down on paper, and also reassess fork() in the light of modern hardware.

The reaction was interesting to say the least. It’s mostly died down by now, but it spurred some interesting discussion:

A lot of these are interesting and highly informed takes on the paper, sometimes agreeing, sometimes disagreeing, but often taking some quite nuanced position in between.

Orran also posted a great conversation between him and his collaborator at Red Hat, Uli Drepper, about the topic:

The four of us feel pretty happy with how the paper turned out, but I think it’s worth emphasizing a few points:

  1. We’re not Microsoft! Andrew works at MSR, but the rest of us have little connection with the company. This paper is certainly not representative of, or instigated by, Microsoft.

    Quite a few comments assumed this was a “Microsoft whitepaper”, whereas it’s actually an academic position paper written by 4 researchers who know each other, one of whom happens to be at MSR. The rest of us are all at Universities.

  2. We’re not dissing Unix! Unix (and its clones) are an amazing thing, and we all use it daily (I’m writing this on my Linux laptop). More than that, its safe to say that every new OS built since the 1980s has been defined in reference to Unix, either because it is more or less a copy of Unix architecturally, or explicitly an attempt to do something different.

Unix was a minimalist, simple, elegant OS written in a short time by people who deeply understood how these things work. In this respect, fork() was a very minor piece of the puzzle - the least-programming-effort way to create a new process by copying out the state to swap in 27 assembly instructions.

What I find fascinating is how, since then, fork() has come to dominate the OS. As we show in the paper, in a modern Unix-like OS like Linux or BSD, the semantics of fork() touch and constrain the design of every part of the kernel, and quite a bit of user space as well.

In a sense, today, Unix is fork() - once you’ve decided you want fork() to be fast, all the rest follows from good engineering principles.

Conversely, if you really want to explore an alternative OS design for modern hardware, you have to give up on fork()

I’m looking forward to Andrew’s presentation…

Written by Timothy Roscoe