もうfork() + exec()だけに頼らない！モダンなプロセス生成のすすめ

伝統的な「fork() + exec()」の組み合わせから脱却し、より効率的で現代的なプロセス生成手法を探求するトピックです。システムのパフォーマンスと安全性を最大化するために、私たちはどのような選択肢を持つべきなのでしょうか？

Chenのパッチが却下されたのは驚きじゃないな。極めてニッチなユースケースで、サポートする価値がない。シェル開発者の視点から言えば、「fork()やexec()を隠蔽しない（現在の実装とは異なる）ネイティブな実装なら歓迎するだろう」という締めの言葉に同意する。

最近まさにこの問題にぶつかったんだ。forkされたプロセスでより多くのファイル記述子を閉じる必要があって、変なバグが出たよ。「現在のプロセスのクローンが欲しい」なんて、自分の経験からすると「完全に新しいプロセスが欲しい」という要望よりずっと稀なんだけどね。後者を直接表現する方法がなくて、クローンした後に後処理で修正するという近似方法でしか対応できないのは、正直どうかしてる。

fork() + exec() モデルの優れた点は、forkした後に既存のあらゆるAPIを使って設定を行えることだ。これまで見てきた代替案の呼び出しメソッドはどれも根本的に劣っているように見える。設定オプションをすべて引数として追加する必要があるし、後で拡張可能にしつつ複雑化させないように実装するのが難しいからだ。

fork()は比較的高コストなシステムコールだ。子プロセスのためにプロセス状態全体（メモリを含む）をコピーしなければならない。長年にわたり多くの最適化が行われてきたが、forkは依然として本質的にコストの高い操作だ。さらに悪いことに、fork()の直後にはexec()が続くことが多く、子プロセスのためにせっかくコピーしたメモリをすべて破棄してしまうことになる。

Copy-on-write（書き込み時コピー）への言及がないのは奇妙だな。メモリをすべてコピーしなくて済むようにする最適化手法なのに。

この議論に関連する論文だ： "A fork() in the road": https://www.microsoft.com/en-us/research/wp-content/uploads/... (https://www.microsoft.com/en-us/research/wp-content/uploads/2019/04/fork-hotos19.pdf)

概要
通説では、Unixのfork()とexec()という風変わりな組み合わせによるプロセス生成は素晴らしい設計だとされている。しかし我々は、forkとは1970年代のマシンとプログラムのための賢いハックであり、その有用性はとうの昔に過ぎ去り、今や負債になっていると主張する。forkが現代のプログラマーにとってどれほど恐ろしい抽象化であるか、それがOSの実装をいかに妥協させているかをカタログ化し、代替案を提示する。

OSの設計者および実装者として、forkが第一級のOSプリミティブとして存在し続けることがシステム研究を阻害していることを認め、非推奨にするべきだ。教育者としては、forkを学生が最初に触れるプロセス生成メカニズムではなく、歴史的遺物として教えるべきである。

fork()が安価だという誤解は妙に多いよね……。プロセスサイズに対して常にO(N)の計算量だし、昔からずっとそうだよ。

確かにCopy-on-writeではあるけど、プロセスのサイズとそれを表現するために必要なページテーブルエントリの数には線形な関係があるんだ。

Forkは最初に学んだ時から概念的にひどいものだと思っていた。何か一つ（プロセスの開始）をしたいだけなのに、全く別の無関係なこと（プロセスをフォークする）をする謎の呪文を使わなければならないなんてね。

記事にある「一つのプロセスが大量のgitサブプロセスを生成する」という例を扱う最適な方法が何なのか気になる。長期間実行される親操作の中で、何度もゼロからgitを起動するのは明らかに筋が悪い。でも、同じ結果を得るための低コストな抽象化って何だろう？

exec/forkを置き換える際の問題は、新しいプロセスを細かく設定したい場面が多いことだ。例えば、シグナルハンドラの設定、ファイル記述子の開閉、名前空間の切り替え、seccompの設定、権限の調整など。これらを行うためのシステムコールはすべて現在のプロセスにのみ適用されるため、それらを置き換える何かが必要になる。記事の提案は、これ専用の新しいAPIを作成するというものだった。

僕のアイデアは、新しいシステムコール（例えば「spawn」）を作ることだ。空の新しいプロセスを作成し、そこに軽量な「ローダー」を読み込んで、任意の構成データを渡す。ローダーがプロセスを設定してメインプログラムをexec()するんだ。これならメモリをforkする必要を避けつつ既存のAPIを使い続けられるが、ファイル記述子などの複製は依然として必要になるだろうね。

もしforkとexecが（CoWの性質を超えて）持続的かつ代数的な振る舞いを示せたら、もっと便利で面白い使い方ができるんじゃないか。例えば遅延評価に使うとかさ。

へえ、LWNは記事を読むためにクリックが必要になったのか。これって逆効果だと思うな（障害を差し込んでまで無理やり見せようとするのは、ユーザーを怒らせたり侮辱したりするだけで、課金してくれる可能性を下げそう）。