Provided by: manpages-ja-dev_0.5.0.0.20180315+dfsg-1_all 
名前
vfork - 子プロセスを生成し親プロセスを停止させる
書式
#include <sys/types.h>
#include <unistd.h>
pid_t vfork(void);
glibc 向けの機能検査マクロの要件 (feature_test_macros(7) 参照):
vfork():
glibc 2.12 以降:
_BSD_SOURCE ||
(_XOPEN_SOURCE >= 500 ||
_XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED) &&
!(_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700)
glibc 2.12 より前: _BSD_SOURCE || _XOPEN_SOURCE >= 500 ||
_XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
説明
規格の説明
(POSIX.1 より引用) vfork() 関数は fork(2) と同じ働きをするが、 vfork() で作成されたプロ
セスが vfork() からの返り値を格納している pid_t 型の変数以外を変更したり、 vfork() を呼び
出している関数から return したり、 _exit(2) や exec(3) 族の関数をコールする前に他の関数を
コールした場合の動作が 未定義であるという点が異なる。
LINUX での説明
vfork() は fork(2) と全く同じように呼び出したプロセスの子プロセスを生成する。 詳しい説明
と返り値、エラーについては fork(2) を参照すること。
vfork() は clone(2) の特殊な場合である。 親プロセスのページテーブルのコピーを行わずに新
しいプロセスを 作成するために使用する。これは性能に敏感なアプリケーションにおいて 子プロセ
スを生成してすぐに execve(2) する場合に有用かもしれない。
vfork() は fork(2) と違い、子プロセスが終了するか、 execve(2) をコールするまで呼び出し元の
スレッドを停止 (suspend) させる。 子プロセスの終了は、_exit(2) の呼び出しによる通常終
了、致命的なシグナルの 配送後の異常終了の二つのケースがある。 この時点までは、子プロセスは
スタックを含む全てのメモリーを親プロセスと共有する。 子プロセスは現在の関数から return し
てはならず、 exit(3) もコールしてはならないが、_exit(2) ならばコールしてもよい。
fork(2) と同様に、 vfork() で作成された子プロセスは、 (ファイルディスクリプター、シグナル
配送定義、カレントワーキングディレクトリなどの) 呼び出し元のプロセスの各種の属性を継承す
る。 vfork() では、上で説明した仮想アドレス空間の扱いだけが異なる。
親プロセスへ送られたシグナルは、子プロセスが親プロセスのメモリーを解放した後 (すなわち、子
プロセスが終了するか execve(2) を呼んだ後) に到着する。
歴史的な説明
Linux において fork(2) は書き込み時コピー (copy-on-write) ページを使用して実装されてい
る。 そのため fork(2) を使用することによって被る損害は親プロセスのページテーブルを 複製す
るために必要な時間とメモリーだけである。 しかしながら、忌しき昔には fork(2) は呼び出した
プロセスのデータ空間の全てのコピーしていたが、 これはしばしば不必要であった。なぜなら、た
いていはすぐ後に exec(3) を実行していたからである。 この場合の効率を上げるために BSD は
vfork() システムコールを導入して親プロセスのアドレス空間を完全にコピー するかわりに、
execve(2) をコールするか exit が起きるまで親プロセスのメモリーと制御スレッド を借りるよう
にした。 親プロセスは子プロセスがその資源を使用している間は停止された。 vfork() は使いに
くいものであった: 例えば、親プロセスの変数を変更しな いようにするためにはどの変数がレジス
ターに保持されているかを知らな ければならなかった。
準拠
4.3BSD; POSIX.1-2001 (廃止予定とされている)。 POSIX.1-2008 では vfork() の規定が削除されて
いる。
vfork() コールは他のオペレーティングシステムの同名のコールと ちょっと似 ているかもしれな
い。規格が vfork() に要求していることは、 fork(2) に要 求していることよりは弱い。したがっ
て、 両者を同じものとして実装しても、規格に 準拠していることになる。 特にプログラマー
は、子プロセスが終了するか execve(2) を呼び出すまで親プロセスが停止していることや、メモ
リーを共有するこ とによる特殊な動作をあてにすべきではない。
注意
vfork() の動作は構造的な欠陥と考える人もいるだろうし、 BSD のマニュアルには、「このシステ
ムコールは妥当なシステム共有機構が実装さ れた場合には削除される。ユーザーは vfork() のメモ
リー共有機能に依存するべき ではない。何故ならば、このシステムコール が削除された場合に
は、それは fork(2) の同義語とされるからである。」と書かれている。しかしながら、 最近のメモ
リー管理ハードウェアにより fork(2) と vfork() の間の性能差が 減ったとはいえ、 Linux や他の
システムで vfork() が残されているのには いくつか理由がある:
* 性能に厳しいアプリケーションでは、 vfork() により得られる 小さな性能上のメリットが必要
な場合がある。
* vfork() はメモリー管理ユニット (MMU) を持たないシステムでも実装すること ができるが、そ
のようなシステムで fork(2) を実装することはできない。 (POSIX.1-2008 では vfork() が標準
から削除された。 posix_spawn(3) 関数の POSIX の原理 (rationale) には、 fork(2)+exec(3)
と等価な機能を提供する posix_spawn(3) は、 MMU を持たないシステムでも実装できるように設
計されたとの注記がある。)
Linux での注意
pthread_atfork(3) を使って設定された fork ハンドラーは NPTL スレッドライブラリコールを採
用したマルチスレッドプログラムでは 呼び出されない。一方、LinuxThreads スレッドライブラリを
使った プログラムでは、fork ハンドラーは呼び出される。 (Linux のスレッドライブラリの説明は
pthreads(7) を参照。)
vfork() の呼び出しは、以下の flags を指定して clone(2) を呼び出す のと等価である。
CLONE_VM | CLONE_VFORK | SIGCHLD
歴史
vfork() システムコールは 3.0BSD に現われた。 4.4BSD において fork(2) の同義語となった
が、NetBSD では再び導入された。 ⟨http://www.netbsd.org/Documentation/kernel/vfork.html⟩ を
参照。 Linux では 2.2.0-pre6 あたりまでは fork(2) と等価であった。(i386 では) 2.2.0-pre9
から (他のアーキテクチャーでは 少し遅れて) 独立したシステムコールとなった。 glibc でのサ
ポートは glibc-2.0.112 で追加された。
バグ
シグナルの扱いの詳細は不明瞭でシステムごとに異っている。 BSD のマニュアルには、 「デッド
ロック状態になる可能性があるので vfork() の途中の子プロセスに SIGTTOU や SIGTTIN シグナル
を送信してはならない; さらに出力や ioctl は許されるが、入力を試みた場合には結果はファイル
終端 (EOF) になる。」 と書かれている。
関連項目
clone(2), execve(2), fork(2), unshare(2), wait(2)
この文書について
この man ページは Linux man-pages プロジェクトのリリース 3.79 の一部 である。プロジェクト
の説明とバグ報告に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。