問題タブ [thread-abort]

私は C# アプリケーションに変更を加えるよう依頼された Java プログラマーです。私は C# を使って 1 週間が経ちましたが、ついにドキュメントを見ても解決策が見つからず、Google で検索しても解決策が見つからないところまで来ました。

この場合、MSMQ に到着するメッセージを処理する Windows サービスがあります。メッセージが受信されると、現在リッスンしているスレッドがそれを取得し、数秒かかる操作を実行するためにオフになります。

GettingAMessage() には、メッセージをリッスンする次の行があります。

問題は、Stop() メソッドが呼び出され、MSMQ にメッセージが送信されない場合、すべてのスレッドがそこで待機してメッセージを待機することです。タイムアウトを使用してみましたが、その方法は私にはエレガントではないようです (そして、タスク ファクトリに切り替えたので、現在それらを実装する方法がわかりません)。これに対する私の解決策は、各スレッドの参照を配列に追加して、それらをキャンセルできるようにすることでした。以下は、作成後に各ワーカー スレッドによって呼び出されます。

そして、によって中止されることになっています

これがスレッドをシャットダウンしない理由について何かアドバイスはありますか? (または、さらに良いことに、ts.Wait() を適切にキャンセルする方法をどこで探すべきか誰か教えてもらえますか?)

次のシナリオを検討してください

スレッドを中止することは悪いことだという議論はさておき、なぜこのコードはタスクを Faulted 状態にしないのでしょうか? ただし、catch ブロックまたは呼び出しを削除する

トリックを行うようです

この質問を調査した結果: Rethrowing exception in Task doesn't make the Task to go to faulted state、理解できない非常に奇妙な動作に気付きましたThreadAbortException。

今、私はそれThreadAbortExceptionが非常に特別な種類の例外であることを知っています. そして、それが言うとき、ドキュメントはそれについてかなり明確です:

ThreadAbortExceptionキャッチできる特別な例外ですが、catchブロックの最後で自動的に再び発生します。

シナリオ #1 : 文書化された動作。

予想どおり、ThreadAbortExceptionは自動的に再スローされ、次の出力が得られます。

シナリオ #2 : 興味深いのは、catchブロックで別の例外をスローすることにしたときです。

この場合、 がスローされたにもかかわらず、文書化された動作が確実に保持されるようにApplicationException、が再スローされると想定しました。ThreadAbortException驚いたことに、これが結果の出力です。

はApplicationException実際に交換して、投げられるのを防ぎThreadAbortExceptionましたか?!?

シナリオ #3 : 最後に、さらに興味深いことに、既存の例外処理をもう 1 つのtry-catchレイヤーでラップします。

今、私は何を期待すべきかよくわかりません。外側のcatchブロックでキャッチされるのはどの例外ですか? でしょうApplicationExceptionか？もしそうなら、それは私が例外を飲み込み、実際にwill never be reached文字列を出力することができるということですか?

これは実際の出力です:

catch上記の出力から、外側のブロックが実際に をキャッチしているように見えますApplicationException。しかし、その catchブロックの終わりまでにThreadAbortException、突然、何もないところから再び現れて、再び投げ出されますか?

質問: 誰かがシナリオ #2 と #3 を説明し、調整してもらえますか? シナリオ 2 でThreadAbortException、予期せず別の例外に置き換えられたように見えるのはなぜですか? ThreadAbortExceptionしかし、シナリオ #3 では、ずっとそこにいたように見えますか? これはどのように起こっていますか？この動作はどこかに文書化されていますか?

これは、非常にグリッチなサードパーティ ライブラリ コードを使用する私のソリューションのコードの簡略化されたバージョンです。

一部のストリームでは、コンストラクターがGlitchyThirdPartyComponent完全にフリークアウトし、多くの CPU パワーとメモリを消費し始め、OutOfMemoryException発生するまで終了しません (どこかで無限ループのようなにおいがします)。

GetThirdPartyComponentまだ実行中の場合、特定のタイムアウト後に呼び出して実行を中止する最も安全な方法を見つけようとしています。

考えられる解決策をいくつか調べましたが、適切な解決策はないようです。これにはいくつかの理由があります。

1. サードパーティ ライブラリのソース コードにアクセスできません。すべてのアセンブリは難読化されているため、逆アセンブルもありません
2. GlitchyThirdPartyComponentシリアル化できないため、クロスアプリドメインまたはクロスプロセス ソリューションはありません
3. GlitchyThirdPartyComponentほとんどの場合、(インターフェイスの外観から) COM を使用するためThread.Abort、非常に信頼性の低いオプションです。
4. 別のサードパーティ ライブラリを使用するか、現在のライブラリ ベンダーにバグ修正を依頼することは可能ですが、これらの解決策には時間がかかり、私の問題はできるだけ早く修正する必要があります。

では、この状況で私は何をすべきでしょうか？ここで本当にThread.Abort最善の解決策はありますか？

私の状況では、ジョブを実行するために複数のスレッドを作成しています。たとえば、「ジョブは何らかのデータを処理することです」と言うことができます。ユーザーが「停止」ボタンを押すとすぐに、これらすべてのスレッドを中止し、データベース内のジョブのステータスを更新したいと考えています。

StartJobThread はジョブを実行している関数です。

現在実行中のすべてのスレッドをキャンセルする方法を教えてください。また、進行中のジョブの ID を取得するにはどうすればよいですか。データベースでステータスを更新できるようにします。