X-Git-Url: http://git.osdn.net/view?a=blobdiff_plain;f=draft%2Fman2%2Fclone.2;h=6b855b2eac6c930ddc8c2b03d3fbd7d595132c03;hb=fe231d72006b46400bc8bf48d8bca24b62994b25;hp=f2153aa8372d80e2ec67953636d5cc0c0397006d;hpb=5e1d43dd8cff93ca6fb21fea939c28233332b846;p=linuxjm%2FLDP_man-pages.git diff --git a/draft/man2/clone.2 b/draft/man2/clone.2 index f2153aa8..6b855b2e 100644 --- a/draft/man2/clone.2 +++ b/draft/man2/clone.2 @@ -112,7 +112,7 @@ _BSD_SOURCE || _SVID_SOURCE メインの説明はラッパー関数に関するものである。 素のシステムコールにおける差分はこのページの最後の方で説明する。 \fBfork\fP(2) とは異なり、\fBclone\fP() では、子プロセス (child process) -と呼び出し元のプロセスとが、メモリ空間、ファイルディスクリプタのテーブル、シグナル・ハンドラのテーブルなどの 実行コンテキストの一部を共有できる。 +と呼び出し元のプロセスとが、メモリ空間、ファイルディスクリプタのテーブル、シグナルハンドラのテーブルなどの 実行コンテキストの一部を共有できる。 (このマニュアルにおける「呼び出し元のプロセス」は、通常は 「親プロセス」と一致する。但し、後述の \fBCLONE_PARENT\fP の項も参照のこと) \fBclone\fP() の主要な使用法はスレッド (threads) を実装することである: @@ -161,13 +161,13 @@ wake (起床) させる。 このアドレスは \fBset_tid_address\fP(2) シ オープン・クローズや、ファイルディスクリプタ・フラグの変更) を行っても、もう一方のプロセスには影響を与えない。 .TP \fBCLONE_FS\fP (Linux 2.0 以降) -\fBCLONE_FS\fP が設定された場合、呼び出し元のプロセスと子プロセスが同じファイル・システム -情報を共有する。ファイル・システム情報は、ファイル・システムのルート (root)、 カレント・ワーキング・ディレクトリ (current -working directory) や umask などである。 呼び出し元のプロセスや子プロセスのどちらか一方によって \fBchroot\fP(2), +\fBCLONE_FS\fP が設定された場合、呼び出し元のプロセスと子プロセスが同じファイルシステム +情報を共有する。ファイルシステム情報は、ファイルシステムのルート (root)、 カレントワーキングディレクトリ (current working +directory) や umask などである。 呼び出し元のプロセスや子プロセスのどちらか一方によって \fBchroot\fP(2), \fBchdir\fP(2), \fBumask\fP(2) が呼び出されると、もう一方のプロセスにも影響が及ぶ。 \fBCLONE_FS\fP が設定されていない場合、子プロセスは、 \fBclone\fP() -が実行された時点での、呼び出し元のプロセスのファイル・システム情報のコピーを 使用する。 これ以降は、呼び出し元のプロセスと子プロセスの一方が +が実行された時点での、呼び出し元のプロセスのファイルシステム情報のコピーを 使用する。 これ以降は、呼び出し元のプロセスと子プロセスの一方が \fBchroot\fP(2), \fBchdir\fP(2), \fBumask\fP(2) を呼び出しても、もう一方のプロセスには影響を与えない。 .TP \fBCLONE_IO\fP (Linux 2.6.25 以降) @@ -320,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 @@ -348,53 +348,52 @@ Linux 2.6.38 で完全に\fI削除\fPされた。 (リストの初期値は空である)。 .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 以降) @@ -433,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, @@ -532,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