カーネルがまだSIGKILLを送るのはなぜですか？ [コピー]

終了したプロセスのユーザースペース部分はSIGKILLこれについて全く知りません。カーネルがすべてを処理する。 （これは、一時ファイル、共有メモリの割り当て、終了したプロセスに代わって、他のプロセス（Xサーバーなど）が保持するリソースなど、一部のリソースが漏洩する可能性があることを意味します。）

ただし、他のプロセスが終了したプロセスがどのように終了したかを知るために、シグナルは依然として転送されなければなりません。親、使用wait終了したプロセスが終了したという情報が得られますSIGKILL。

これ回答部分的に本当です。プロセスを終了すると、メモリを解放する以上の効果があります。しかし、aはSIGKILL肩を叩いたり何かをするような要求ではなく、プロセスが無視または処理できない数少ない信号の1つです。つまり、aはSIGKILL常にカーネルの基本ハンドラによって処理され、ほとんどの信号と同様に、この基本的な操作は信号を受信するプロセスを終了することです。プログラムのユーザースペース部分は信号を見ることもないので、何かをする必要もなく、協力する必要もありません。したがって、プログラムは、信号を受けた後に悪意を持って何らかの方法で誤動作しませんSIGKILL。またはいくつかのプログラミングエラーのため。代わりに、プロセスのカーネル側で信号を処理し、プロセスを終了します。したがって、いくつかの点では、カーネルがプロセスを終了する必要があることをカーネルの他の部分に知らせることによってプロセスを直接終了します。

プログラミングの観点から、カーネルがプログラムを終了しようとするとき（主にリソース不足、特に利用可能なRAMが不足しているため）、プロセスを終了する必要があるときに実行するコードをコピーする2つの可能性があります。終了またはシグナルを伝達する関数を呼び出すと、プロセスを終了するために必要なすべてが処理されることがわかります。 2番目のアプローチは、初期の労力を減らすだけでなく、重複コードを維持する必要がないため、長期的に作業量を減らします。

他の非常に良い答えを完了するための信号の仕組みの概要：

プロセスの実行は、ユーザー空間またはカーネル空間の2つのモードで発生できます。ユーザー空間では、プロセスはプログラムのコードを実行し、カーネル空間ではプロセスはカーネルのコードを実行します。プロセスはタスクを実行するために可能なときはいつでもユーザー空間で実行されますが、実行中にプロセスを作成するときにカーネルスペースに入ります。システムコール（これは、ファイルの読み取りなど、システム自体のハードウェアまたは共有リソースに対する特権タスクに必要な場合、または実行中に中断された場合に必要です。

シグナルは、2 つの状況、つまりプロセスがシステム呼び出しを完了した後にユーザー空間に戻ったとき、またはシステム呼び出しから起きたときに処理されます。邪魔されない睡眠実行を再開します。どちらの場合も、プロセスはカーネル空間に存在します。まず、カーネルはプロセスに保留中のシグナルがあることを確認し、それに対処します。たとえば、シグナルに対してハンドラが定義されている場合、プロセスはユーザー空間に戻ったときにそれを実行します。本人の言葉通り、KILL事件は捕まえられないという点で特別だ。したがって、カーネルの場合、実際には単純なケースです。ユーザ空間への復帰は取り消され、プロセスは直ちに終了する。つまり、ユーザー空間でコードを実行せずにメモリを解放し、親プロセスを終了します。死などのニュースを知らせます。

終了すると、プロセスはプロセスのコンテキスト/環境でメモリ解放、セマフォの解放、ファイルのクローズ、いくつかの統計などのいくつかのクリーンアップ操作を実行します。カーネルはそれを複製できますが、プロセスをタップして自殺するように要求する方が簡単です。