boost :: visual Interrupt（）で待機しているスレッドは、boost :: thread Interrupt（）が呼び出されても中断されません。例： http ：//www.justsoftwaresolutions.co.uk/threading/thread-interruption-in-boost-thread-library.html
これには正当な理由がありますか？
もちろん、boost :: this_thread ::interruption_point（）を手動で配置して回避することもできます。
現在のスレッドに割り込みフラグが設定されていて、動作がスレッドを一時停止して割り込みハンドラーを呼び出すのとは根本的に異なる場合、ブースト割り込みポイントは例外をスローします。ブーストのどちらのロックも、pthreadロックの動作に従う中断ポイントではありません。待機中にpthreadロックがシグナルハンドラーによって中断されると、ハンドラーが完了するまで待機し続けます。同様に、ブーストスレッドを中断としてマークするか、boost::mutex::lock()待機boost::barrier::wait()し続ける場合。
もう1つは、barrier::wait()ロックを取得せずに途中で戻ることを許可した場合、例外をスローする前にバリアを待機しているスレッドのプールから現在のスレッドの登録を解除する必要があり、実装がより複雑になります。また、ロックを取得せずにlock / waitメソッドを返すことができるため、コードがより複雑になります。
一般的に、それは単にデザインの選択だと思います。
中断ポイントであるメソッドを見ると、通常、それらはより長い時間（boost::this_thread::sleep()、 ）スリープすることを意図しておりboost::condition_variable_any::wait()、それらのコンポーネントもシグナルによって終了していることがわかります。ここでの例外は、割り込みポイントであるですが、信号を処理した後も待機し続けます。sleeppthread_cond_waitboost::thread::join()pthread_join