重複の可能性:
長時間実行されているスレッドを適切に停止する方法は?
こんにちは。
操作を実行する必要があるバックグラウンド スレッドがありますが、リソースが破損している場合を除いて、常に正常に動作します。その場合、スレッドは Execute メソッドの Load (そのリソースへの) 呼び出しでブロックされます。
その場合、スレッドは Terminate メソッド (メイン スレッドからの呼び出し) に応答せず、ブロックされます。
だから、私の質問は次のとおりです。ブロックされたスレッドを（メインスレッドから）適切に終了する方法。いいえ、リソースをロードするクラスを変更することも、リソースが破損しているかどうかを以前から知ることもできません。
TerminateThread()WinAPI 関数を探します。ここで役に立つ説明が見つかるか、MSDNのドキュメントを参照してください。
もちろん、終了後、スレッドに割り当てられたリソースが解放されていないかどうかを確認し、適切に解放する必要があります。
アップデート
はい、TerminateThread（コメントで指定されているように）使用は悪い習慣です。私はこの意見に賛成です。しかし、「本当に使用する必要がある場合でも、決して使用しないでください」という推奨は、私の観点からは強すぎて、非常に理論的です。設計上の欠陥とバグのあるサードパーティ製ライブラリに満ちた現実世界。
問題に与えられた情報は、この具体的な状況について正しい決定を下すには不十分です。たとえば、代替手段がないなどの一時的な回避策である可能性があります。
したがって、理論的な観点からの正しい答えは、「処理されたバックグラウンドスレッドでステップを「フリーズ」する方法を制御できない場合、プロセスを適切に終了する方法はありません。」
実用的な観点から、正しい答えは次のとおりです。「処理されたバックグラウンドスレッドでステップを「フリーズ」する方法を制御できない場合、プロセスを適切に終了する方法はありません。しかし、制御できないが、それでもそのような機能が必要であることに気付いた場合は、TerminateThread() API 呼び出しを使用してください」
TerminateThread と TerminateProcess について:
- プロセスの作成/終了には、スレッドの作成/終了よりも多くのリソースが必要です - プロセス
の作成/終了はより複雑 => バグが発生する場所が増えます
- TerminateProcess はすぐには終了せず、I/O 操作が完了するのを待ちます ( MSDN ) => 読み取り中にリモート共有フォルダーが使用できなくなるシナリオや、その他の同様の I/O シナリオでは選択できません。
- プロセスの作成と終了には、スレッドの作成よりも多くのユーザー権限が必要です。MSDN のこちらとこちらを比較してください
リソースの解放について:
スレッドの終了時にスレッド スタックが自動的に解放されます (MSDN で説明されています)。リソースは主にリソースであり、バックグラウンド スレッドとの通信のためにメイン スレッドによって割り当てられます。たとえば、メモリ構造、ミューテックスなど。