すべての子プロセスが終了するまで親プロセスが待機(終了)するのはなぜですか?

すべての子プロセスが終了するまで親プロセスが待機(終了)するのはなぜですか?

親プロセスには、すべての子プロセスが終了するのを待つように強制する方法がないことがわかります。しかし、これは次のルールです。また、子プロセスが終了する前に親プロセスが終了すると、子プロセスは孤児プロセスになります。内部にプロセス。しかし、私が理解していないのは、子プロセスが孤児になり、子プロセスによって採用された場合の問題ですか?内部にプロセス。終了するまで親プロセス自体に接続する必要があるのはなぜですか?

答え1

この規則の主な理由は、プロセスが子プロセスを分岐する場合、通常は子プロセスが実行されることです。基本プロセスで実行されると予想される操作の一部です。  フォークと見なされるプログラムの例はありますか?

ここにいくつかの例があります。

  • 集中的な計算を実行するプログラムは、複数のCPU /コアで同時に実行するために独自の複数のコピーをフォークできます。 (このためにスレッドを使用することはおそらくより伝統的かもしれませんが、確かにプロセスをフォークして実行できます。)このようなプログラム可能プロセスごとに単一の出力のみを作成するように設計されています。ただし、基本プロセスがすべての子プロセスが完了するのを待ってから結果をマージするのも一般的です。
  • このようなプログラムには、netcatホスト A から読み取ってホスト B に書き込む 1 つのプロセスと、ホスト B から読み取ってホスト A に書き込む別のプロセスがある場合があります。 (もちろんスレッドでも可能です。)
  • find -execつまり、 の場合xargs(メイン)プログラムの作業はスレーブプログラムを実行することです。 完了するまでお待ちください。  ユーザーが次のように言うとどうなるか想像してください。
    探す。 -type f -exec cp {} /backup';' &&rm -r。
    findすべてのコピーが完了するのを待たずに終了します。

このような場合(およびその他の場合)は、すべての子プロセスが完了するまで基本プログラムの操作は完了しません。したがって、プログラムはすべての子プロセスを待つ前に終了してはいけません。

もちろん、これがフォークを使用できる唯一の方法ではありません。ネットワークサーバー(FTPやメールなど)には、通常、着信接続を受信し、クライアント接続が行われるたびに子プロセスを分岐する基本プロセスがあります。これらのサブプロセスはいつでも(クライアントによって決定された)終了することができ、基本プロセスはサブプロセスを待つ理由はありません。

子プロセスが終了したときにどの「親」/リッパープロセスに関連付けられているかについての情報は実際には問題になりません。

答え2

この規則の主な理由は、親プロセスが子プロセスの前に終了すると、子プロセスの終了コードが失われ、子プロセスがしばらくゾンビ状態のままになる可能性があることです。

子プロセスが終了した後、終了コードを読み取るまで残り、メモリを消費します。これはゾンビプロセスと呼ばれるものです。つまり、死んだが収穫(削除)されません。

通常、終了コードを読み、ゾンビプロセスが完全に消えることを許可するのは親プロセスの責任です。両親は子供を追跡し続ける必要があるため、この問題がすぐに解決されることを願っています。親プロセスがこれを行わないと、リソースリークが発生します。

親プロセスが子プロセスの前に終了すると、initはその責任を引き継いでいますが、それをすぐに認識できない可能性があるため、子プロセスはより長い間ゾンビとして残り、より多くのリソースを占有する可能性があります。

編集:明確にするために、ゾンビ状態のプロセスはすべてのメモリを保持しません。プロセスがゾンビになる前に、ほとんどのメモリが解放されます。これはプロセステーブルに保持されている項目です。プロセステーブルエントリが多いほど、カーネルがプロセス関連アクティビティを実行するのに時間がかかります。

関連情報