- あるプロセスが別のプロセスにシグナルを送信する場合、受信プロセスはどのような状況で、実行が再スケジュールされるまで待機しますか?
- インストールされたシグナルハンドラはどのような状況ですぐに呼び出されますか?
- 対応するシグナルハンドラーを直接呼び出す場合と比較して、シグナルを発生させるときにプロセスにかかるオーバーヘッドはどれくらいですか?
2 に答える
シグナルの配信について、TLPIは、タスクが次にスケジュールされたとき、カーネルモードからユーザーモードに切り替えたとき、またはタスクがすでに実行されているときに「すぐに」(おそらく「すぐに」発生する必要がある)、シグナルが「通常」配信されると述べています。最初に割り込みを発生させます。そうでない場合、どのようにそれを行うことができますか)。まあ、これが何を意味するにせよ、それは厳密に拘束力はありませんが、何が起こるかに非常に近いです。
リアルタイム信号と「通常の」信号、および同期的に生成される「通常の」信号を区別する必要があります。ほとんどの場合、ハードウェアイベント(セグメンテーション違反など)が原因で発生し、そうでない信号(非同期で生成される)が原因です。 )。
リアルタイム信号はキューに入れられますが、通常の信号はキューに入れられません。つまり、通常の信号の実装は、ビットマスクとして機能するタスクごとの1つの単語のようなものにすぎない可能性が高いということです。
「通常の」信号を生成することはビットを設定することを意味し、OSが次に信号を配信する必要があるかどうかを決定するときに、ゼロに対してワードをテストし、必要に応じてどのビットが設定されたかを判断し、信号ハンドラーを呼び出します(s)もしあれば、それに応じて。
これを知る必要がある唯一の実際的な理由は、信号を「失う」可能性があるためです。最初の信号が配信される前に2つ以上の信号が生成された場合でも、それは1つの信号だけです。
リアルタイムシグナルの実装(実装に依存する長さまでキューに入れる必要があります)は、明らかにはるかに複雑です。
ハードウェアイベント(セグメンテーション違反など)が原因で発生するシグナルは、プロセスがそれ自体を呼び出した場合と同じ方法で同期的に生成さkill
れます(22.4章TLPI)。つまり、2つの理由で「すぐに」配信されます。まず、他のことをするのは意味がありません。次に、トラップハンドラーが戻ったときにカーネル/ユーザーの切り替えがすでに発生しています。したがって、配信は常に「すぐに」行われます。
基本的に、信号は非同期です。プロセススケジューラなどの要因が原因でいつになるかわからないため、シグナルを受信したときにコードを実行するためにシグナルハンドラに依存しています。信号を送信する待ち時間は、クロック速度に基づくハードウェア/ソフトウェア割り込みに基づいています。
Linuxで何かがどのように実装されているかを知りたい場合は、POSIX標準を確認してください。
シグナルに関する優れた情報:
http://www.gnu.org/software/libc/manual/html_node/index.html#toc_Signal-処理
信号が生成されると、保留になります。通常、それはほんの短い期間保留されたままになり、その後、通知されたプロセスに配信されます。ただし、その種類の信号が現在ブロックされている場合は、その種類の信号がブロック解除されるまで、無期限に保留されたままになる可能性があります。ブロックを解除すると、すぐに配信されます。
別の抜粋:
信号が配信されると、すぐに、または長い遅延の後に、その信号に対して指定されたアクションが実行されます。