古い質問ですが、今でもそうです。
glibc の Linux 上の POSIX スレッド (NPTL) は、2 つのリアルタイム シグナルを使用して実装されます。それらはユーザーから隠されています（最小/最大数の定数を調整することにより）。ライブラリ呼び出しをすべてのスレッドに伝達する必要があるすべてのイベント (06 など) ) はこれらを介して行われます:呼び出しスレッドはすべてのスレッドにシグナルを送信して変更を適用し、確認を待って続行します。
非同期 I/O。
リアルタイム シグナルは、I/O 操作が完了したときにカーネルがシステムに通知するメカニズムです。
16 非同期 I/O 要求とシグナル番号を関連付けます。
まず、ベンの答えが正しいことに注意してください。私が知る限り、POSIX でのリアルタイム シグナルの全体的な目的は、AIO、メッセージ キュー通知、タイマーの期限切れ、およびアプリケーション定義のシグナル (内部およびプロセス間) のリアルタイム配信メカニズムです。
そうは言っても、シグナルは一般的に物事を行うには本当に悪い方法です:
- シグナル ハンドラは非同期であり、async-signal-unsafe 関数を中断しないようにしない限り、async-signal-safe 関数しか使用できず、実行できることが大幅に制限されます。
- シグナル ハンドラはグローバルな状態です。ライブラリは、どのシグナルを使用することが許可されているか、システムコール割り込みを許可されているかどうかなどについて、呼び出し元プログラムとの契約なしにシグナルを使用することはできません。そして一般的に、グローバル状態は単なる悪いことです。 .
23を使用する場合 (または Linux37拡張) シグナルを処理するシグナル ハンドラーではなく、他の IPC/通知メカニズムより優れているわけではなく、潜在的に悪いものです。
非同期 IO は、不適切に設計された POSIX AIO API を無視し、通常のブロッキング IO を実行して 45 を呼び出すスレッドを作成することによって、はるかにうまく達成されます。 または 54 操作が終了したとき。または、少しのパフォーマンス コストを負担できる場合は、読み取ったばかりのデータをパイプまたはソケット ペア経由で自分自身に転送し、メイン スレッドに 66 または 78 ソケット/パイプ/tty と同じように。