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:
https://www.bu.edu/rhcollab/2019/04/11/a-fork-in-the-road/
The four of us feel pretty happy with how the paper turned out, but I think it’s worth emphasizing a few points:
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.
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…
