上記以外
documentation for the handler routineに記載されているように:
信号が受信されると、システムは、機能を実行するためのプロセスで新しいスレッドを作成します。
特定のスレッドがコンソール制御信号に応答する必要がある場合は、コードに最も適したスレッド間通信方法を使用して、そのスレッドに連絡するハンドラルーチンを作成するのは自分の責任です。
シグナルが処理されている間は、既存のスレッドは通常どおり実行されるため、ハンドラルーチンがスレッドセーフであることを確認することもあなたの責任です。
コンソール制御信号は、POSIX信号と似ていません。 1つは、一般にコンソールアプリケーション(GUIアプリケーションはコンソール制御信号を受信しません)にのみ影響し、別のものはIPCメカニズムとして使用するように設計されていないか意図していません。もちろん、既存のスレッドを中断することはありません。
Microsoft Cランタイムは、標準で要求されているようにC信号を実装していますが、POSIX信号とほとんど同じです。最も顕著なのは、インプロセスのみです。特殊なケースとして、SIGINTハンドラを設定すると、コンソールコントロールハンドラとして実装されますが、この機能はis officially unsupportedであり、使用することをお勧めします。
ええ、私はPOSIX信号をまったく使用したくないのですが、これらの問題を解決するためのWindowsの方法を知りたいと思います。 スレッドを正常に終了させたい場合は、ハンドラから他のスレッドにウィンドウメッセージを送信してそこからクローズプロシージャを管理することをお勧めしますか? –
@EärendilBaggins:スレッドの終了を通知するより良い方法は、手動リセット[Event Object](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682655.aspx)を使用することです。スレッドは定期的にチェックを行い、通知されると終了します。 [WaitForMultipleObjects](https://msdn.microsoft.com/en-us/library/windows/desktop/ms687025.aspx)を呼び出すスレッド終了を待つことができます。 – IInspectable
IMOでは、ウィンドウメッセージは、通常はメインスレッドのみであるウィンドウメッセージループを自然に持つスレッドに対してのみ使用することをお勧めします。他のスレッドについては、彼らが何をやっているかによって異なりますが、イベントオブジェクト(IInspectableが示唆するように)はしばしば良い汎用的な選択肢です。 APCはより洗練されているかもしれませんが、それはスレッドのメインループがどのように見えるかによって異なり、グリップを得るのが少し難しくなります。 –