微软研究人员发表论文称用于创建进程的 fork 系统调用方式已经很落后，并且对操作系统的研究与发展产生了极大的负面影响，需要淘汰，作者同时提出了替代方案。

　　相信每位开发者都对操作系统中的 fork () 有一定的了解，至少知道它是用来创建进程的。fork 系统调用方式在 20 世纪 70 年代被创造出来，它通常与 exec () 组合使用，非常简单却很强大，被认为是一种天才式的设计、Unix 的伟大思想，至今 50 余年一直作为 POSIX 操作系统的原语存在，同时几乎每个 Unix shell、主要 Web 和数据库服务器、Google Chrome、Redis 甚至 Node.js 都使用 fork。

　　然而微软系统研究实验室 Redmond 的研究人员 3 月份却发表了一篇论文，表示 fork 作为操作系统原语继续存在，阻碍了对操作系统的研究，“它是来自另一个时代的遗物，不适合现代系统，并且会带来一系列负面影响”，研究人员认为是时候将 fork 淘汰了。

　　fork 简单已成神话

　　论文中承认了 fork API 的优点，包括简单与缓解并发性，也肯定了 fork 在历史上的重要贡献，但更多地是列出了它在现代操作系统研究与发展中的弊端。

　　研究人员认为 fork 本身就存在许多问题，另一方面，fork 在操作系统的研究与发展上也起了限制作用，论文指出有明确的证据表明支持 fork 限制了 OS 体系结构的变化，并限制了操作系统适应硬件演进的能力。

　　乍一看可能会觉得 fork 很简单，而这也是它的一大特征，但是实际上，“这是一个具有欺骗性的神话”。

　　fork 的语义已经影响了每个创建进程状态的新 API 的设计，POSIX 规范现在列出了关于如何将父状态复制到子进度的 25 个特殊情况，包括文件锁定、定时器、异步 IO 操作与跟踪等。此外，许多系统调用标志控制 fork 关于内存映射（Linux madvise () 标记 MADV_DONTFORK/DOFORK/WIPEONFORK 等）、文件描述符（O_CLOEXEC、FD_CLOEXEC）和线程（pthread_atfork ()）的行为。任何重要的操作系统工具都必须通过 fork 记录其行为，并且用户模式库必须做好准备，以便随时 fork 它们的状态。fork 已经不再简单。

　　fork 不是线程安全的，Unix 进程支持线程，但 fork 创建的子进程只有一个线程（调用线程的副本），当一个线程在 fork 时，如果另一个线程此时进行内存分配并持有堆锁，任何在子进程中分配内存的尝试（从而获得相同的锁）都将立即发生死锁。

　　fork 很慢，fork 的性能一直是个问题，此前使用写时复制技术使其性能可接受，但是在今天，建立写时复制映射本身都成了一个性能问题，比如 Chrome 在 fork  时会经历了长达 100 毫秒的延迟，Node.js 应用在 exec 之前 fork 时，可以被阻塞几秒钟。fork+exec 与 spawn 的性能对比情况可以通过本文开头的图片直观看到。

　　fork 无法扩展，系统规模的设计首先要避免不必要的共享，但 fork 进程会与其父进程共享所有内容，由于 fork 复制了进程操作系统状态的各个方面，这样复制与引用计数成本会比较低，所以 fork 其实是趋向于将状态集中在单片内核中，这就使得难以实现一些新技术，比如用于安全性和可靠性的内核划分。

　　fork 与异构硬件不兼容，它将进程的抽象与包含它的硬件地址空间混为一谈。fork 将进程的定义限制为单个地址空间，并且是在某个核心上运行的单个线程。但现代硬件和在其上运行的程序并不是这样，硬件异构化越来越严重，使用有内核旁路 NIC 的 DPDK 或带有 GPU 的 OpenCL 的进程无法安全地 fork，因为操作系统无法复制 NIC/GPU 上的进程状态。这个问题至少已经困扰了 GPU 程序员十年，而随着未来的芯片上系统包含越来越多的状态加速器，情况只会变得更糟。

　　“GET THE FORK OUT OF MY OS!”

　　论文提出了替代 fork 的方案：包括一个高级 Spawn API 和一个低级类微内核 API 的组合。涉及到 posix_spawn ()、vfork ()、跨进程操作、clone ()、改进写时复制内存等内容。

　　fork 的问题越来越严重，作者最后总结出必须做三件事来纠正这种情况，不仅要弃用 fork，还要改善替代方案，同时纠正我们关于 fork 的教学内容，不能再错误地宣扬 fork 的能力与设计水平。

　　论文地址：https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road