fork系統調用方式成爲負擔，須要淘汰

微軟研究人員發表論文稱用於建立進程的 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 的能力與設計水平.