私は、POSIXスレッドとPOSIXシグナルがどのように相互作用するかについての複雑さを理解しようとしてきました。特に、私は興味があります：
これが必要な理由については、TclXパッケージを変換してスレッドをサポートする方法、または分割して少なくともいくつかの便利なパーツでスレッドをサポートする方法を研究しています。信号は、特に興味深い部分の1つです。
回答:
- シグナルが配信されるスレッドを制御するための最良の方法は何ですか？
@ zoli2kが示しているように、処理するすべてのシグナルを処理する単一のスレッド（またはそれぞれが特定のシグナルの責任を持つスレッドのセット）を明示的に指定することは、優れた手法です。
- シグナルが到着したことを別のスレッド（実際にはビジーである可能性があります）に伝える最良の方法は何ですか？[...]
- シグナルが発生したという情報を他のスレッドに渡すことを安全に処理するにはどうすればよいですか？これはシグナルハンドラーで発生する必要がありますか？
「ベスト」とは言いませんが、これが私の推奨事項です。
で必要なすべてのシグナルをブロックしmainて、すべてのスレッドがそのシグナルマスクを継承するようにします。次に、特別なシグナル受信スレッドをシグナル駆動型イベントループとして作成し、新しく到着したシグナルを他のスレッド内通信としてディスパッチします。
これを行う最も簡単な方法は、sigwaitinfoまたはsigtimedwaitを使用してループ内のシグナルをスレッドに受け入れさせることです。次に、スレッドは信号を何らかの方法で変換します。おそらく、をブロードキャストしpthread_cond_t、より多くのI / Oで他のスレッドをウェイクアップし、アプリケーション固有のスレッドセーフキューでコマンドをキューに入れます。
あるいは、特別なスレッドにより、シグナルをシグナルハンドラーに配信し、シグナルを処理する準備ができた場合にのみ配信のためにマスクを解除することができます。（sigwaitただし、ハンドラーを介したシグナル配信は、ファミリーを介したシグナルの受け入れよりもエラーが発生しやすい傾向があります。）この場合、レシーバーのシグナルハンドラーはsig_atomic_t、フラグの設定、バイトの呼び出しsigaddset(&signals_i_have_seen_recently, latest_sig)、write（）などの単純で非同期のシグナルセーフアクションを実行します。非ブロッキング自己パイプ等、そして、バックそのマスクメインループにおいて、スレッドは、上記のように他のスレッドへの信号の受信を通信します。
（更新された@cafsigwaitは、アプローチが優れていることを正しく指摘しています。）
sigwaitinfo()（またはsigtimedwait()）でループし、最後の段落で説明したように、アプリケーションの残りの部分にそれらをディスパッチします。
POSIX標準によれば、すべてのスレッドはシステム上で同じPIDで表示される必要があり、を使用pthread_sigmask()してすべてのスレッドの信号ブロックマスクを定義できます。
PIDごとに定義できるシグナルハンドラーは1つだけなので、1つのスレッドですべてのシグナルを処理しpthread_cancel()、実行中のスレッドをキャンセルする必要がある場合は送信することをお勧めします。pthread_kill()スレッドのクリーンアップ関数を定義できるため、これは反対の方法として推奨されます。
一部の古いシステムでは、適切なカーネルサポートがないため、実行中のスレッドのPIDが親スレッドのPIDと異なる場合があります。Linux 2.4でのlinuxThreadsを使用した信号処理については、FAQを参照してください。
make menuconfig、uClibcの新しく複製されたgitマスターブランチで実行しようとしました。POSIXスレッドの実装として古いLinuxThreadsと新しいNPTLのどちらかを選択できますが、2012年現在のヘルプでは、NPTLを選択しないことを推奨しています。そのため、システムが最近十分な数のLinuxカーネルを実行している場合でも、最新の組み込みLinuxシステムでは、廃止されたLinuxThreads実装が使用されているのが一般的です。
私が今いるところ：
私はまだを通じてソートに持ってsignal対sigaction、pselect、sigwait、sigaltstack、、その他のこまごまとPOSIXの（非POSIX）APIの全体の束。
IMHO、Unix Vシグナル、およびposixスレッドはうまく混ざりません。Unix Vは1970年です。POSIXは1980年です;）
キャンセルポイントがあり、1つのアプリケーションでシグナルとpthreadを許可すると、最終的には各呼び出しの周りにループを作成することになり、驚くべきことにEINTRを返す可能性があります。
したがって、LinuxまたはQNXでマルチスレッドをプログラムする必要がある（いくつかの）ケースで私がしたことは、すべての（1つを除く）スレッドのすべてのシグナルをマスクすることでした。
Unix Vシグナルが到着すると、プロセスはスタックを切り替えます（これは、Unix Vではプロセス内で取得できるのと同じくらいの同時実行性でした）。
ここにある他の投稿が示唆しているように、どのposixスレッドがそのスタック切り替えの犠牲になるかをシステムに伝えることが可能かもしれません。
シグナルハンドラスレッドを機能させることができたら、問題は残ります。シグナル情報を文明化されたものに変換する方法です。他のスレッドが使用できます。スレッド間通信のインフラストラクチャが必要です。便利なパターンの1つは、各スレッドがインプロセスメッセージングメカニズムのターゲットであるアクターパターンです。
したがって、他のスレッドをキャンセルしたり、それら（または他の奇妙なもの）を強制終了したりする代わりに、SignalコンテキストからSignalハンドラースレッドにSignalをマーシャリングしてから、アクターパターン通信メカニズムを使用して、意味的に有用なメッセージをそれらのアクターに送信する必要があります。信号関連の情報が必要な人。