Fork

fork（フォーク）とは、実行中のプロセスのコピーを生成するシステムコールである。UNIXおよびUnix系オペレーティングシステムにおける基本的なプロセス生成手段として位置づけられる。並行処理の開始や別プログラムの実行準備のために用いられる。

fork() により生成された子プロセスは呼び出し元の親プロセスと戻り値で区別され、生成直後は同一の仮想アドレス空間を持つが、コピーオンライト機構により物理メモリの複製は必要時まで行われない。

Unixにおけるforkの重要性 Unixにとってforkは重要な機構概念であり、フィルタを要素としてパイプライン処理を構成するUNIX哲学の重要な部分を担っている。 Unixでのフィルタは標準入力を入力とし標準出力を出力とする（通常小さな）プログラムである。シェルがフィルタをパイプで連結することで、複雑な処理を実現できる。例えば次のようにfind(1)コマンドの出力をwc(1)コマンドの入力に連結すると、拡張子が ".cpp" のファイルをカレントディレクトリ配下で探し、見つかったファイル数を表示できる。 $ find . -name "*.cpp" -print | wc -l このコマンド行を入力すると、シェルは自分自身をforkし、プロセス間通信の1つであるパイプを使って find コマンドの出力を wc コマンドの入力に結びつける。パイプは2つの新たなファイル識別子を生成し、2つの子プロセスを生成する（それぞれ find と wc に対応）。2つの子プロセスはまず dup2(2) で対応するパイプのファイル識別子を複製して標準入力と標準出力に置き換える。そしてそれぞれの子プロセスがexec(3)ファミリのシステムコールを使って、実行すべきコマンドのプログラムで自身をオーバーレイする。

より一般的に、シェルはユーザーがコマンド行を入力するたびにforkを行っている。子プロセスはシェルがforkを行うことで生成され、子プロセスがexecでオーバーレイを行い、実行すべきプログラムのコードをマッピングする。

パイプライン処理以外の重要なforkの応用として、POSIXセッションの開始がある。POSIXの仕様上、セッションを新たに開始することができるのはプロセスグループのリーダーではないプロセスに限られる。一方、制御端末を持たない独立したセッションに所属することが要求されるデーモンは単純にシェルから実行を開始するとシェルによるジョブ管理のためにプロセスグループのリーダーとなってしまうため、このままでは新規にセッションを開始できない。この問題を回避するため、デーモンとなるプロセスはforkを実行し、実際の処理を子プロセス側で行うことが必須となる。子プロセスは親プロセスと同じプロセスグループに所属する一方、PIDは明らかに親プロセスとは異なるものになるのでプロセスグループのリーダーではなく、ゆえに新規にセッションを開始することができる。

プロセスのアドレス空間実行ファイルを実行しようとすると、プロセスが生成される。実行ファイルはセグメントと呼ばれるブロックにグループ化されたバイナリコードを含んでいる。各セグメントは特定の種類のデータを格納するのに使われる。典型的なELF形式の実行ファイルには、以下のようなセグメントが存在する。

— 実行可能なコードを格納したセグメント .bss — 初期値がゼロのデータを格納したセグメント — 初期値のあるデータを格納したセグメント symtab — プログラムのシンボル群（例えば、関数名、変数名など）を格納したセグメント interp — 使用すべきインタプリタの名前を格納したセグメント

readelf コマンドを使えば、ELF形式のファイルの詳細を表示できる。そのようなファイルを実行するためにメモリ上にロードすると、セグメント群がメモリにロードされることになる。実行ファイル全体を連続なメモリ位置にロードする必要はない。メモリはページと呼ばれる同じ大きさ（通常4KB）の部分に分けられている。したがって実行ファイルをメモリにロードする際、実行ファイル内のそれぞれの位置がそれぞれ異なるページに置かれる（ページ群は連続とは限らない）。大きさが10KBのELF形式の実行ファイルがあるとする。そのOSのサポートするページサイズが4KBなら、そのファイルは4KB、4KB、2KBという3つの部分に分けてロードされる（他にコールスタックも必要）。この3つのフレームはメモリ中の任意のフリーなページに置くことができる正確には、これはページング方式の仮想記憶の場合である。また、.bssは実行ファイル上では対応するデータが存在せず、単に仮想空間の範囲だけが確保される。。

forkとページ共有 fork()システムコールを実行すると、本来ならばOSが子プロセスのために親プロセスの持つ全ページを物理メモリ上の別の位置にコピーすることになる。しかし、場合によってはその必要はない。子プロセスがfork()直後に "exec" システムコール（実行ファイルを実行するときに使用する）を実行する場合や終了する場合である。親プロセスが何らかのコマンドを実行するためだけに子プロセスを生成した場合、子プロセスのアドレス空間は実行すべきコマンドですぐに置換されるので、親プロセスのページ群をコピーする必要はない。

そのため、コピーオンライト (COW) という技法が使われる。COWでは、fork時に親プロセスのページ群を子プロセスにコピーしない。その代わりページ群は親プロセスと子プロセスの間で共有される。親子いずれかのプロセスがページの内容を更新しようとしたとき、そのページだけコピーを作成し、書き込もうとしたプロセスの当該ページだけが更新される。書き込んだプロセスはその後その新たにコピーしたページを使用する。もう一方のプロセス（共有ページに書き込まなかったプロセス）は、コピー元のページを使用し続ける（共有状態は解消される）。何らかのプロセスが書き込もうとしたときにページがコピーされるので、この技法をコピーオンライトと呼ぶ。

vforkとページ共有 vfork はもう1つのプロセス生成用UNIXシステムコールである。vfork()システムコールで子プロセスを生成すると、子プロセスが終了するかexecve()ファミリのシステムコールで新たな実行イメージに切り換えるまでそのシステムコールの延長上で親プロセスが待ち合わせる。vforkでも親プロセスと子プロセスでページ群を共有するが、コピーオンライトは必要としない。子プロセスが共有ページに更新を加えてもコピーは作成せず、親プロセスからもその更新が見える。ページを全くコピーしないので、子プロセスでコマンドを実行する場合には非常に効率的である。

実装によっては vfork() は fork() と同じである。

vfork()とfork()の唯一の違いは、親プロセスと子プロセスがコードとデータを共有できる点である。これによって複製は劇的に高速化されるが、使い方を誤ると親プロセスの一貫性が壊れる危険性がある。

直後に exec または _exit() を呼び出す以外のvfork()の使用は推奨されない。特にLinuxのmanページではvforkそのものの使用が推奨されていないVFORK。

vfork()で生成した子プロセスがvfork()を呼び出したルーチンからさらに外側に復帰した場合、親プロセスのコールスタックを書き変えてしまうので、vfork()から親プロセスが戻ったときの動作を保証できない。また、execせずに子プロセスを終了する場合、_exit()ではなくexit()を使用すると、標準I/Oチャネルをフラッシュしてクローズするため親プロセスの標準I/O構造にダメージを与える危険性がある。なお、fork()の場合でも子プロセスがexit()を呼び出すのは危険である。

vfork()後に子プロセスでシグナルハンドラが呼び出された場合、子プロセスの他のコードと同じ規則に従う必要がある。

MMUのないシステム組み込みシステムではメモリ管理ユニット (MMU) が存在しない場合があり、fork() でのコピーオンライトの実装ができないことがある。システムがプロセス毎のアドレス空間を他の何らかの機構で（例えばセグメント方式で）サポートする場合、プロセスの使用する全メモリをコピーすれば実質的には同じである。しかしそれは非常に時間がかかるし、多くの場合すぐに別の実行ファイルのイメージで書き換えられるので無駄である。

全プロセスが単一のアドレス空間を共有している場合、例えば全メモリページをスワップしてコンテキストスイッチするというfork()の実装も考えられる。μClinuxベースのOSなどの組み込みOSが採用しているのは、fork() を廃して vfork() だけを実装するという方法である。そのため、forkを使っているところを全てvforkで動作できるように書き換えている。

Unix以外でのフォーク Unix系やLinuxでのfork機構は、基盤となっているハードウェアにある種の前提を課している。リニアなメモリ空間とページング機構を持ち、連続なアドレス範囲のメモリコピーを効率的に行えるという前提である。VMS（現在のOpenVMS）の当初の設計では、コピー操作後に少数の具体的なアドレスの内容書き換えを行うフォークは危険だとみなされていた。現在のプロセス状態におけるエラーが子プロセスにコピーされるかもしれない。そこでプロセスの（産卵）というメタファーが使われた。すなわち、新しいプロセスのメモリレイアウトの各コンポーネントを一から新たに構築する。ソフトウェア工学的観点からすれば後者（スポーン）の手法の方がきれいで安全だが、フォークの方が効率的なのでよく使われている。スポーン方式は後にマイクロソフトのOSで採用された。

fork を使ったコード例 C の例 #include <stdio.h> /* printf, stderr, fprintf */ #include <sys/types.h> /* pid_t */ #include <unistd.h> /* _exit, fork */ #include <stdlib.h> /* exit */ #include <errno.h> /* errno */

int main(void) { pid_t pid;

/* 子プロセスと親プロセスの両方の出力が * 標準出力に書かれる。 * 両者は同時に動作する。 */ pid = fork(); if (pid == -1)

/* エラー: * fork()が-1を返す場合、エラーが起きたことを示す。 * 例えばプロセス数が制限に達した場合など。 */ fprintf(stderr, "can't fork, error %d\n", errno); exit(EXIT_FAILURE);

if (pid == 0)

/* 子プロセス: * fork()が0を返す場合、子プロセスである。 * 1秒に1ずつ、10まで数える。 */ int j; for (j = 0; j < 10; j++)

printf("child: %d\n", j); sleep(1);

_exit(0); /* exit() を使わない点に注意 */

else

/* fork() が正の数を返す場合、親プロセスである。 * その値は生成した子プロセスのPIDである。 * ここでも10まで数える。 */ int i; for (i = 0; i < 10; i++)

printf("parent: %d\n", i); sleep(1);

exit(0);

return 0; }

Perl の例 #!/usr/bin/env perl -w use strict;

if (fork) { # 親プロセス foreach my $i (0 .. 9) { print "Parent: $i\n"; sleep 1;

else { # 子プロセス foreach my $i (0 .. 9) { print "Child: $i\n"; sleep 1;

exit(0); # forkした子プロセスの終了 }

exit(0); # 親プロセスの終了

Python の例 #!/usr/bin/env python3 import os import sys import time

def doTask(): "This function create a task that will be a daemon" with open("/tmp/tarefa.log", "w") as log_file: while True: log_file.write("{}\n".format(time.ctime())) log_file.flush() time.sleep(2)

def createDaemon(): "This function create a service/Daemon that will execute a det. task" try: pid = os.fork()

if pid > 0: print("PID: {}".format(pid)) sys.exit()

except OSError as error: print("Unable to fork. Error: {} ({})".format(error.errno, error.strerror)) sys.exit(1)

else: doTask()

if __name__ == "__main__": createDaemon()

Fork-Exec は、UNIXで一般的に使われる手法であり、新たなプログラムをプロセスとして実行する。は親プロセスを2つの同一内容のプロセスに（フォークの先のように）分岐させるシステムコールである。によって子プロセスが親プロセスのコピーとして生成され、子プロセスがシステムコールを呼び出すことで（子プロセス）自身の内容を置き換える。

親プロセスが子プロセスの終了を待ち合わせる場合、子プロセスの終了コードを受け取ることができる。子プロセスがゾンビプロセスとなるのを防ぐには、親プロセスがシステムコールを使用する必要があり、そのタイミングは定期的でもよいし、SIGCHLDシグナルを受け取った際でもよい。

子プロセスがを呼び出すと、そのアドレス空間の内容は全て失われ、指定されたプログラムを実行するためのアドレス空間のマッピングが新しく設定される。これをオーバーレイと呼ぶ。アドレス空間は全て置き換えられるが、オープン済みファイルのファイル記述子群は close-on-exec が指定されたときだけ時に自動的にクローズされる。この特徴を利用して、を呼び出す前にパイプを作成しておき、で指定された新しいプログラムとの通信を行うというUNIX特有の手法が実現されている。

なお、Microsoft Windows では単独に相当するシステムコールがなく、fork-exec モデルを採用していない。代わりにファミリ関数がで定義されており、fork-exec に相当する働きをする。

マルチスレッド下での挙動プロセスがマルチスレッドである場合、はそれを呼び出したスレッドのみを子プロセスへコピーする。その他のスレッドは子プロセスには現れない。この仕様は、を呼び出したスレッド以外のスレッドがカーネル中でスリープしていた場合、そのようなスレッドをコピーすることが技術上困難であることに依る。一方、何らかのスレッドが獲得していたロックにあっては、アドレス空間のコピーにより子プロセスでも同じ状態を継続する。

この仕様に起因する制限として、子プロセスでは非同期シグナル安全な処理のみを実行する必要がある。特に、他のスレッドがロックを所有していた場合、子プロセスがそのロックを獲得しようとするとロックを解放する手段がないためデッドロックに陥ることに注意しなければならない。

非同期シグナル安全性の非同期シグナル安全性は、その実装および実行状況の両者から影響を受けるため、保証が難しい。具体的には、以下の性質が要求されることが知られている。

実装スレッドのキャンセレーションポイントを持たない。実行状況を使用しない、ないしはこれを用いて登録したハンドラが全て非同期シグナル安全である。

におけるキャンセレーションポイントの要求は、その処理中にプロセス全体の状態を安定させるため、を呼び出したスレッド以外のスレッドを一旦中断させる必要があることに由来する。万一カーネル内で中断できない処理を実行中のスレッドがあった場合、そのような状況から脱出するにはを呼び出したスレッドをキャンセルしなければならない。実際ににキャンセレーションポイントをサポートさせるかどうかは実装に依存する。

このような問題に対し、非同期シグナル安全性を保証したが提供されていることがある。はキャンセレーションポイントを実装せず、かつを用いて登録したハンドラを実行しない。これらの変更をもっては非同期シグナル安全性を保証する。なお、マルチスレッド環境下にて子プロセスがを実行するまでの処理に非同期シグナル安全性が要求されるのはも同様である。

やの非同期シグナル安全性が特に要求される用途として、予期せぬシグナルを受信した場合、そのハンドラから子プロセスとしてデバッガを起動するものがある。このポストでは「は非同期シグナル安全」としているが、実際には#非同期シグナル安全性の節にあるようにを呼び出すのが望ましい。なお、も非同期シグナル安全であることからこのような用途が成立する。

脚注

参考文献 "File descriptors across fork(2)/exec(2)", Operating Systems (Course 304-427B), Franco Callari, Electrical Engineering Department, McGill University Advanced Programming in the UNIX Environment, W. Richard Stevens, Addison-Wesley Unix Power Tools, Jerry Peek, Tim O'Reilly, Mike Loukides, O'Reilly,

Źródło i licencja