Anecdotes: Notes on the History of Fork and Join

As part of a PhD on code forking in open source software, Linus Nyman looked into the origins of how the practice came to be called forking.¹ This search led to the early history of the fork system call. Having not previously seen such a history published, here we look back at the birth of the fork system call to share what was learned, as remembered by its pioneers.

The fork call allows a process (or running program) to create new processes. The original is deemed the parent process, and the newly created one its child. On multiprocessor systems, these processes can run concurrently in parallel.² Since its birth 50 years ago, the fork has remained a central element of modern computing, both with regard to software development principles and, by extension, to hardware design, which increasingly accommodates parallelism in process execution.

Fork System Call Imagined

The year was 1962. Melvin Conway, later to become known for Conway’s law,³ was troubled by what seemed an unnecessary inefficiency in computing. As Conway recalled,

I was in the US Air Force at the time—involved with computer procurement—and I noticed that no vendor was distinguishing between “processor” and “process.” That is, when a proposal involved a multiprocessor design, each processor was committed to a single process.⁴

By late 1962, Conway had begun contemplating the idea of using a record to carry the status of a process. In the spring of 1963, “as an intellectual exercise,” Conway wrote a paper suggesting a means of implementing parallel processing in a multiprocessor system design, using what he called “fork and join” system calls. Figure 1 shows the original illustration of the fork and join system call.

Conway presented a paper, “A Multiprocessor System Design,” later that fall at the American Federation of Information Processing Societies (AFIPS) Joint Computer Conference, and it was published in the conference proceedings.^5,6 Conway explained the basic idea in the paper:

Fundamental to the concepts presented here is the principle, not yet commonly accepted, that parallel paths in a program need not bear fixed relationships to the processors of a multiprocessor system executing that program.⁷

Although Conway had not come across anyone offering a solution to this inefficiency, he is nonetheless modest about the novelty of his suggestion:

Of course I do not claim to have invented that idea, since it must be present in all implementations in some form or other.⁴

Indeed, there were some who had addressed the issue before him. In a footnote in the article, Conway noted that “the fork-join notion has been around for a while,” albeit under different names, such as branch in the CL-II and Burroughs D825 AOSP computers, SIMU in the Gamma 60 computer, and branch transfer or BRT in the conceptual machine discussed by P. Richards.⁸ Reflecting on that footnote, Conway stated:

I only vaguely remember the origin of the footnote. The fact of its placement as a footnote suggests to me that it was added after submission of the paper at the urging of the editors, who may have noted that the technical concept was already in use. I conjecture that I added the footnote to assert the first use of the word in this technical context. If that is indeed the history of the footnote, the acceptance of my wording by the editors suggests their consent.⁴

In fact, there was a second paper at that same 1963 Fall Joint Computer Conference in which the terms “fork” and “join” were also used.⁹

Although the idea was not Conway’s alone, the publication of his paper describing it seems to have codified the idea and become the impetus for its widespread implementation in later computer systems. The system call’s popularity was not due to Conway himself implementing the fork—he did not. Nor was it due to the paper having had a significant impact at the conference—Conway recalled that it did not. Rather, it appears due to the paper finding its way to Project Genie.

Project Genie

Project Genie...