GUI でいくつかのバックグラウンド スレッドを実行しています。現在、私は個人的な Thread キャンセル コードを実装していますが、スレッドには IsBackground プロパティがあり、MSDN によると、スレッド自体がキャンセルされます。
厄介な Thread.Abort() に行くことはわかっていますが、このバックグラウンドスレッドでは、適切な状態を維持する必要があるか、適切なクリーンアップが必要なことは何もありません。
ユーザーがバックグラウンド スレッドの途中でアプリケーションを閉じた場合のクラッシュを回避しようとしています。マルチスレッドのシナリオはテストが非常に難しいため、この件についてご意見をお聞かせください。
基本的に、自分のコードをロールバックする代わりに、IsBackground = True を設定して、残りを忘れるべきでしょうか?
Jonathan Greensted の投稿には、以下についての優れた要約がありIsBackgroundます。
IsBackground プロパティを使用すると、スレッドがフォアグラウンド (UI) スレッドかバックグラウンド スレッドかをランタイムに伝えることができます。デフォルトでは、このプロパティを変更しない限り、すべてのスレッドがフォアグラウンド スレッドとして作成されます。
では、なぜ私たちは気にするのでしょうか?
.NET ランタイムは、最後のフォアグラウンド スレッドが終了すると特別な処理を行います。つまり、すべてのバックグラウンド スレッドを中止し、アプリケーションを終了します。(Thread.Abort が悪いことはわかっていますが、とにかくアプリケーションがシャットダウンされている場合、その問題の持続時間は非常に限られています。)
別の言い方をすれば、バックグラウンド スレッドで行われている作業は、アプリケーションが終了するときにいつでも停止しても問題ないのでしょうか?
そうでない場合は、おそらくフォアグラウンド スレッドにする必要があります。そのため、ファイル ハンドルを処理したり、データベース接続を開いたりするスレッドは、アプリケーションが終了する前にこのスレッドが終了するのを待機するフォアグラウンドにするのが理想的です。
プロパティのMSDNページには次のように記載されています。IsBackground
スレッドは、バックグラウンド スレッドまたはフォアグラウンド スレッドのいずれかです。バックグラウンド スレッドは、バックグラウンド スレッドがプロセスの終了を妨げないことを除いて、フォアグラウンド スレッドと同じです。プロセスに属するすべてのフォアグラウンド スレッドが終了すると、共通言語ランタイムはプロセスを終了します。残りのバックグラウンド スレッドはすべて停止され、完了しません。
したがって、接続を開いたままにしたり、データベースを半分書き込んだりしないように、スレッドを非常に防御的にする必要があることを意味します。重要なものは、アプリケーションの終了を防ぐフォアグラウンドスレッドにある必要があります。完了するまで。
Thread.Abort は例外をスローするため、コードが finally/using を使用するように正しく記述されている場合は、適切に失敗し、すべてのリソースを解放する必要があります。
編集
おそらくもう少し詳しく説明する必要があります。まず、例外のタイプは ThreadAbortException です。興味深いのは、捕まえて何もしなくても消えないということです。つまり、キャッチ ブロックを離れるとすぐに、スローされ続けます。これは、例外をキャッチしてそれを飲み込むという (通常は悪い) 慣行によって、スレッドが中止されるのを止めないようにするためです。実際にアボートを停止したい場合は、例外をキャッチしてから、Thread.ResetAbort を呼び出す必要があります。
これはリソースによると思います。たとえば、プロセスが終了すると、ソケットは安全に閉じられます。一部のリソースについては、スレッドを終了する前に解放したほうがよいでしょう。