X-Git-Url: http://git.osdn.net/view?a=blobdiff_plain;f=release%2Fman2%2Fclone.2;h=6b855b2eac6c930ddc8c2b03d3fbd7d595132c03;hb=94cd7e81dd3e371b227523c463ff897ddefcd75b;hp=aae0e3173196d2030c8167a717a1587a4e235895;hpb=a2b0f650fa5e3f097a33752f9ee5626f8d678fd8;p=linuxjm%2FLDP_man-pages.git diff --git a/release/man2/clone.2 b/release/man2/clone.2 index aae0e317..6b855b2e 100644 --- a/release/man2/clone.2 +++ b/release/man2/clone.2 @@ -66,7 +66,7 @@ .\" Updated 2012-05-08, Akihiro MOTOKI .\" Updated 2013-05-06, Akihiro MOTOKI .\" -.TH CLONE 2 2013\-04\-16 Linux "Linux Programmer's Manual" +.TH CLONE 2 2014\-02\-27 Linux "Linux Programmer's Manual" .SH 名前 clone, __clone2 \- 子プロセスを作成する .SH 書式 @@ -98,7 +98,7 @@ glibc ラッパー関数の機能検査マクロの要件 (\fBfeature_test_macro glibc 2.14 以降: _GNU_SOURCE .TP 4 -.\" FIXME See http://sources.redhat.com/bugzilla/show_bug.cgi?id=4749 +.\" See http://sources.redhat.com/bugzilla/show_bug.cgi?id=4749 glibc 2.14 より前: _BSD_SOURCE || _SVID_SOURCE /* _GNU_SOURCE も定義される */ @@ -112,7 +112,7 @@ _BSD_SOURCE || _SVID_SOURCE メインの説明はラッパー関数に関するものである。 素のシステムコールにおける差分はこのページの最後の方で説明する。 \fBfork\fP(2) とは異なり、\fBclone\fP() では、子プロセス (child process) -と呼び出し元のプロセスとが、メモリ空間、ファイルディスクリプタのテーブル、シグナル・ハンドラのテーブルなどの 実行コンテキストの一部を共有できる。 +と呼び出し元のプロセスとが、メモリ空間、ファイルディスクリプタのテーブル、シグナルハンドラのテーブルなどの 実行コンテキストの一部を共有できる。 (このマニュアルにおける「呼び出し元のプロセス」は、通常は 「親プロセス」と一致する。但し、後述の \fBCLONE_PARENT\fP の項も参照のこと) \fBclone\fP() の主要な使用法はスレッド (threads) を実装することである: @@ -161,16 +161,14 @@ wake (起床) させる。 このアドレスは \fBset_tid_address\fP(2) シ オープン・クローズや、ファイルディスクリプタ・フラグの変更) を行っても、もう一方のプロセスには影響を与えない。 .TP \fBCLONE_FS\fP (Linux 2.0 以降) -If \fBCLONE_FS\fP is set, the caller and the child process share the same -filesystem information. This includes the root of the filesystem, the -current working directory, and the umask. Any call to \fBchroot\fP(2), -\fBchdir\fP(2), or \fBumask\fP(2) performed by the calling process or the child -process also affects the other process. +\fBCLONE_FS\fP が設定された場合、呼び出し元のプロセスと子プロセスが同じファイルシステム +情報を共有する。ファイルシステム情報は、ファイルシステムのルート (root)、 カレントワーキングディレクトリ (current working +directory) や umask などである。 呼び出し元のプロセスや子プロセスのどちらか一方によって \fBchroot\fP(2), +\fBchdir\fP(2), \fBumask\fP(2) が呼び出されると、もう一方のプロセスにも影響が及ぶ。 -If \fBCLONE_FS\fP is not set, the child process works on a copy of the -filesystem information of the calling process at the time of the \fBclone\fP() -call. Calls to \fBchroot\fP(2), \fBchdir\fP(2), \fBumask\fP(2) performed later by -one of the processes do not affect the other process. +\fBCLONE_FS\fP が設定されていない場合、子プロセスは、 \fBclone\fP() +が実行された時点での、呼び出し元のプロセスのファイルシステム情報のコピーを 使用する。 これ以降は、呼び出し元のプロセスと子プロセスの一方が +\fBchroot\fP(2), \fBchdir\fP(2), \fBumask\fP(2) を呼び出しても、もう一方のプロセスには影響を与えない。 .TP \fBCLONE_IO\fP (Linux 2.6.25 以降) \fBCLONE_IO\fP が設定された場合、新しいプロセスは呼び出し元のプロセスと I/O コンテキストを共有する。 @@ -195,7 +193,7 @@ I/O コンテキストは、ディスクスケジュールの I/O スコープ .\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f .\" https://lwn.net/Articles/312232/ -IPC 名前空間は、独立の System V IPC オブジェクト空間 (\fBsvipc\fP(7) 参照) を提供する 。 (Linux 2.6.30 +IPC 名前空間は、独立の System\ V IPC オブジェクト空間 (\fBsvipc\fP(7) 参照) を提供する 。 (Linux 2.6.30 以降では) 独立した POSIX メッセージキュー空間 (\fBmq_overview\fP(7) 参照) も提供される。 これらの IPC 機構に共通の特徴として、 IPC オブジェクトはファイルシステムのパス名とは違った仕組みで識別されるという点がある。 @@ -322,15 +320,15 @@ UTS 名前空間は、 \fBuname\fP(2) が返す識別子の集合である。 (\fBset_thread_area\fP(2) を参照のこと) .TP \fBCLONE_SIGHAND\fP (Linux 2.0 以降) -\fBCLONE_SIGHAND\fP が設定された場合、呼び出し元のプロセスと子プロセスは同じシグナル・ハン +\fBCLONE_SIGHAND\fP が設定された場合、呼び出し元のプロセスと子プロセスは同じシグナルハン ドラのテーブルを共有する。呼び出し元のプロセスまたは子プロセスのどちらかが \fBsigaction\fP(2) を呼び出してシグナルに対応する動作を変更した場合、 もう一方のプロセスのシグナル動作も変更される。 但し、呼び出し元のプロセスと子プロセスは、 -プロセス毎に、シグナル・マスク (signal mask) と処理待ちシグナルの集合 を持っている。このため、あるプロセスは、 +プロセス毎に、シグナルマスク (signal mask) と処理待ちシグナルの集合 を持っている。このため、あるプロセスは、 \fBsigprocmask\fP(2) を使用して、もう一方のプロセスに影響を与えずに シグナルを禁止 (block) したり許可 (unblock) したりできる。 \fBCLONE_SIGHAND\fP が設定されていない場合、子プロセスは \fBclone\fP() -が実行された時点での、呼び出し元のプロセスのシグナル・ハンドラの コピーを継承する。これ以降は、一方のプロセスが \fBsigaction\fP(2) +が実行された時点での、呼び出し元のプロセスのシグナルハンドラの コピーを継承する。これ以降は、一方のプロセスが \fBsigaction\fP(2) を呼び出しても、もう一方のプロセスには影響を与えない。 Linux 2.6.0\-test6 以降では、 \fBCLONE_SIGHAND\fP を指定する場合、 \fBCLONE_VM\fP も \fIflags\fP @@ -345,57 +343,57 @@ Linux 2.6.0\-test6 以降では、 \fBCLONE_SIGHAND\fP を指定する場合、 Linux 2.6.38 で完全に\fI削除\fPされた。 .TP \fBCLONE_SYSVSEM\fP (Linux 2.5.10 以降) -\fBCLONE_SYSVSEM\fP がセットされると、子プロセスと呼び出し元プロセスは一つの System V セマフォのアンドゥ値リスト +\fBCLONE_SYSVSEM\fP がセットされると、子プロセスと呼び出し元プロセスは一つの System\ V セマフォのアンドゥ値リスト (\fBsemop\fP(2) 参照) を共有する。このフラグがセットされていなければ、 子プロセスは独自のアンドゥリストを持つ (リストの初期値は空である)。 .TP \fBCLONE_THREAD\fP (Linux 2.4.0\-test8以降) -\fBCLONE_THREAD\fP が設定された場合、子プロセスは呼び出し元のプロセスと同じスレッド・グループに 置かれる。 \fBCLONE_THREAD\fP -についての以降の議論を読みやすくするため、 「スレッド」という用語はスレッド・グループの中のプロセスを 参照するのに使うこととする。 +\fBCLONE_THREAD\fP が設定された場合、子プロセスは呼び出し元のプロセスと同じスレッドグループに 置かれる。 \fBCLONE_THREAD\fP +についての以降の議論を読みやすくするため、 「スレッド」という用語はスレッドグループの中のプロセスを 参照するのに使うこととする。 -スレッド・グループは、 スレッド集合で一つの PID を共有するという POSIX スレッドの概念をサポートするために Linux 2.4 -に加えられた機能であった。 内部的には、この共有 PID はいわゆるそのスレッドグループの スレッド・グループ識別子 (TGID) である。 Linux -2.4 以降では、 \fBgetpid\fP(2) の呼び出しではそのプロセスのスレッド・グループ ID を返す。 +スレッドグループは、 スレッド集合で一つの PID を共有するという POSIX スレッドの概念をサポートするために Linux 2.4 +に加えられた機能であった。 内部的には、この共有 PID はいわゆるそのスレッドグループの スレッドグループ識別子 (TGID) である。 Linux +2.4 以降では、 \fBgetpid\fP(2) の呼び出しではそのプロセスのスレッドグループ ID を返す。 あるグループに属するスレッドは (システム全体で) 一意なスレッド ID (TID) で区別できる。新しいスレッドの TID は \fBclone\fP() の呼び出し元へ関数の結果として返され、 スレッドは自分自身の TID を \fBgettid\fP(2) で取得できる。 \fBCLONE_THREAD\fP を指定せずに \fBclone\fP() の呼び出しが行われると、 生成されたスレッドはそのスレッドの TID と同じ値の -TGID を持つ 新しいスレッド・グループに置かれる。このスレッドは 新しいスレッド・グループの「リーダー」である。 +TGID を持つ 新しいスレッドグループに置かれる。このスレッドは 新しいスレッドグループの「リーダー」である。 \fBCLONE_THREAD\fP を指定して作成された新しいスレッドは、 (\fBCLONE_PARENT\fP の場合と同様に) \fBclone\fP() -を呼び出し元と同じ親プロセスを持つ。 そのため、 \fBgetppid\fP(2) を呼ぶと、一つのスレッド・グループに属すスレッドは全て同じ値を返す。 +を呼び出し元と同じ親プロセスを持つ。 そのため、 \fBgetppid\fP(2) を呼ぶと、一つのスレッドグループに属すスレッドは全て同じ値を返す。 \fBCLONE_THREAD\fP で作られたスレッドが終了した際に、 そのスレッドを \fBclone\fP() を使って生成したスレッドには \fBSIGCHLD\fP (もしくは他の終了シグナル) は送信されない。 また、 \fBwait\fP(2) を使って終了したスレッドの状態を取得することもできない (そのようなスレッドは \fIdetached\fP (分離された) といわれる)。 -スレッド・グループに属す全てのスレッドが終了した後、 そのスレッド・グループの親プロセスに \fBSIGCHLD\fP (もしくは他の終了シグナル) -が送られる。 +スレッドグループに属す全てのスレッドが終了した後、 そのスレッドグループの親プロセスに \fBSIGCHLD\fP (もしくは他の終了シグナル) が送られる。 -スレッド・グループに属すいずれかのスレッドが \fBexecve\fP(2) を実行すると、スレッド・グループ・リーダー以外の全てのスレッドは -終了され、新しいプロセスがそのスレッド・グループ・リーダーの下で 実行される。 +スレッドグループに属すいずれかのスレッドが \fBexecve\fP(2) を実行すると、スレッドグループリーダー以外の全てのスレッドは +終了され、新しいプロセスがそのスレッドグループリーダーの下で 実行される。 -スレッド・グループに属すスレッドの一つが \fBfork\fP(2) を使って子プロセスを作成した場合、 スレッド・グループのどのスレッドであっても -その子供を \fBwait\fP(2) できる。 +スレッドグループに属すスレッドの一つが \fBfork\fP(2) を使って子プロセスを作成した場合、 スレッドグループのどのスレッドであっても その子供を +\fBwait\fP(2) できる。 Linux 2.5.35 以降では、 \fBCLONE_THREAD\fP を指定する場合、 \fIflags\fP に \fBCLONE_SIGHAND\fP -も含まれていなければならない。 +も含まれていなければならない (Linux 2.6.0\-test6 以降では、 \fBCLONE_SIGHAND\fP を指定する場合 \fBCLONE_VM\fP +も指定する必要がある点に注意すること)。 -\fBkill\fP(2) を使ってスレッド・グループ全体 (つまり TGID) にシグナルを送ることもできれば、 \fBtgkill\fP(2) +\fBkill\fP(2) を使ってスレッドグループ全体 (つまり TGID) にシグナルを送ることもできれば、 \fBtgkill\fP(2) を使って特定のスレッド (つまり TID) にシグナルを送ることもできる。 シグナルの配送と処理はプロセス全体に影響する: ハンドラを設定していないシグナルがあるスレッドに配送されると、 -そのシグナルはスレッド・グループの全メンバーに影響を及ぼす (終了したり、停止したり、動作を継続したり、無視されたりする)。 +そのシグナルはスレッドグループの全メンバーに影響を及ぼす (終了したり、停止したり、動作を継続したり、無視されたりする)。 各々のスレッドは独自のシグナルマスクを持っており、 \fBsigprocmask\fP(2) で設定できる。 だが、処理待ちのシグナルには、 -\fBkill\fP(2) で送信されるプロセス全体に対するもの (つまり、スレッド・グループの どのメンバーにも配送できるもの) と、 +\fBkill\fP(2) で送信されるプロセス全体に対するもの (つまり、スレッドグループの どのメンバーにも配送できるもの) と、 \fBtgkill\fP(2) で送信される個々のスレッドに対するものがありえる。 \fBsigpending\fP(2) を呼び出すと、プロセス全体に対する処理待ちシグナルと呼び出し元の スレッドに対する処理待ちシグナルを結合したシグナル集合が返される。 -\fBkill\fP(2) を使ってスレッド・グループにシグナルが送られた場合で、 そのスレッド・グループがそのシグナルに対するシグナル・ハンドラが -登録されていたときには、シグナル・ハンドラはスレッド・グループの メンバーのうち、ただ一つのスレッドでだけ起動される。ハンドラが +\fBkill\fP(2) を使ってスレッドグループにシグナルが送られた場合で、 そのスレッドグループがそのシグナルに対するシグナルハンドラが +登録されていたときには、シグナルハンドラはスレッドグループの メンバーのうち、ただ一つのスレッドでだけ起動される。ハンドラが 起動されるスレッドは、そのシグナルを禁止 (block) していない メンバーの中から一つだけが勝手に (arbitrarily) 選ばれる。 -スレッド・グループに属す複数のスレッドが \fBsigwaitinfo\fP(2) を使って同じシグナルを待っている場合、 +スレッドグループに属す複数のスレッドが \fBsigwaitinfo\fP(2) を使って同じシグナルを待っている場合、 これらのスレッドの中から一つをカーネルが勝手に選択し、 そのスレッドが \fBkill (2)\fP を使って送信されたシグナルを受信する。 .TP \fBCLONE_UNTRACED\fP (Linux 2.5.46 以降) @@ -434,7 +432,7 @@ Linux 2.5.35 以降では、 \fBCLONE_THREAD\fP を指定する場合、 \fIflag .in 生のシステムコールのもう一つの違いは、 \fIchild_stack\fP 引き数がゼロでも良いことである。この場合には、どちらかのプロセスが スタックを変更した時に、書き込み時コピー (copy\-on\-write) 方式により -子プロセスがスタック・ページの独立したコピーを得られることが保証される。 この場合、正常に動作させるためには、 \fBCLONE_VM\fP +子プロセスがスタックページの独立したコピーを得られることが保証される。 この場合、正常に動作させるためには、 \fBCLONE_VM\fP オプションを指定してはならない。 いくつかのアーキテクチャでは、システムコールの引き数の順序は上記とは異なっている。 microblaze, ARM, ARM 64, PA\-RISC, @@ -533,14 +531,14 @@ CLONE_THREAD と一緒に指定する必要はなくなった。 このフラグ i386 上では、 \fBclone\fP() は vsyscall 経由ではなく、直接 \fIint $0x80\fP 経由で呼び出すべきである。 .SH バグ -NPTL スレッド・ライブラリを含んでいる GNU C ライブラリのいくつかのバージョン には、 \fBgetpid\fP(2) +NPTL スレッドライブラリを含んでいる GNU C ライブラリのいくつかのバージョン には、 \fBgetpid\fP(2) のラッパー関数が含まれており、このラッパー関数は PID をキャッシュする。 このキャッシュ処理が正しく動作するためには glibc の \fBclone\fP() のラッパー関数での助けが必要だが、現状の実装では、 ある状況下においてキャッシュが最新とならない可能性がある。 特に、 \fBclone\fP() の呼び出し直後にシグナルが子プロセスに配送された場合に、 そのシグナルに対するハンドラ内で \fBgetpid\fP(2) を呼び出すと、それまでに clone のラッパー関数が子プロセスの PID キャッシュを 更新する機会が得られていなければ、呼び出し元プロセス ("親プロセス") の PID が 返される可能性がある。 (この議論では、子プロセスが \fBCLONE_THREAD\fP を使って作成された場合のことは無視している。 子プロセスが \fBCLONE_THREAD\fP を作って作成された場合には、 -呼び出し元と子プロセスは同じスレッド・グループに属すので、 \fBgetpid\fP(2) は子プロセスと \fBclone\fP() +呼び出し元と子プロセスは同じスレッドグループに属すので、 \fBgetpid\fP(2) は子プロセスと \fBclone\fP() を呼び出したプロセスで同じ値を返すのが「正しい」。 キャッシュが最新とならない問題 (stale\-cache problem) は、 \fIflags\fP に \fBCLONE_VM\fP が含まれている場合にも発生しない。) 本当の値を得るためには、次のようなコードを使う必要があるかもしれない。 .nf @@ -555,11 +553,10 @@ NPTL スレッド・ライブラリを含んでいる GNU C ライブラリの .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910 .SH 例 -.SS "別の UTS 名前空間で動作する子プロセスを作成する" 以下のプログラムは、 別の UTS 名前空間で動作する子プロセスを \fBclone\fP() を使って作成する例である。 子プロセスは、自分の UTS 名前空間においてホスト名を変更する。 それから、親プロセスと子プロセスの両方でシステムのホスト名を表示し、 親プロセスと子プロセスの UTS 名前空間でホスト名が異なることを確認する。 このプログラムの使用方法については \fBsetns\fP(2) を参照。 - +.SS プログラムのソース .nf #define _GNU_SOURCE #include @@ -651,6 +648,6 @@ main(int argc, char *argv[]) \fBset_thread_area\fP(2), \fBset_tid_address\fP(2), \fBsetns\fP(2), \fBtkill\fP(2), \fBunshare\fP(2), \fBwait\fP(2), \fBcapabilities\fP(7), \fBpthreads\fP(7) .SH この文書について -この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.54 の一部 +この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.67 の一部 である。プロジェクトの説明とバグ報告に関する情報は http://www.kernel.org/doc/man\-pages/ に書かれている。