17

私はプレゼンテーションに取り組んでいましたが、適切なコンテキストで ActionResult が返されていないため、次は失敗するはずだと考えました。VS で負荷テストを行ったところ、エラーは発生しませんでした。私はそれをデバッグし、スレッドを切り替えていることを知っています。したがって、それは合法的なコードのようです。

ASP.NET は、クライアント アプリのように、それがどのコンテキストまたはスレッド上にあるかを気にしませんか? もしそうなら、AspNetSynchronizationContext はどのような目的を提供しますか? アクション自体に ConfigureAwait を入れるのは適切ではありません。それについて何かが間違っているようです。誰でも説明できますか?

    public async Task<ActionResult> AsyncWithBackendTest()
    {
        var result = await BackendCall().ConfigureAwait(false);
        var server = HttpContext.Server;
        HttpContext.Cache["hello"] = "world";
        return Content(result);
    }
4

3 に答える 3

6

ASP.NETには、多くのクライアントアプリが必要とする「UIスレッド」の必要性がありません(その下のUIフレームワークのため)。そのコンテキストはスレッドアフィニティに関するものではなく、ページの進行状況を追跡するためのものです(および、リクエストのセキュリティコンテキストを持ち運ぶなどの他のこと)

Stephen Toubは、MSDNの記事でこれについて言及しています

同期コンテキストから派生したクラスを提供する環境は、Windowsフォームだけではありません。ASP.NETは、AspNetSynchronizationContextも提供しますが、これは公開されておらず、外部での使用を目的としたものではありません。むしろ、ASP.NET 2.0の非同期ページ機能を容易にするために、ASP.NETの内部で使用されます(詳細については、msdn.microsoft.com / msdnmag / issues / 05/10 / WickedCodeを参照してください)。この実装により、ASP.NETは、すべての未処理の非同期呼び出しが完了するまで、ページ処理の完了を防ぐことができます

同期コンテキストについてもう少し詳しく説明しているのは、昨年のStephenClearyの記事です。

特に図4は、WinForms / WPFの「特定のスレッド」の動作がないことを示していますが、全体が優れた読み物です。

同じアプリケーションに対して複数の操作が同時に完了する場合、AspNetSynchronizationContextは、それらが一度に1つずつ実行されることを保証します。これらはどのスレッドでも実行できますが、そのスレッドには元のページのIDとカルチャがあります。

于 2012-04-04T06:12:33.813 に答える
4

コードでは、基本クラスHttpContextのメンバーです。AsyncController実行中のスレッドの現在のコンテキストではありません。

また、HttpContextリクエストがまだ完了していないため、あなたの場合はまだ有効です。

現時点ではこれをテストすることはできませんが、System.Web.HttpContext.Current代わりにHttpContext.

PS セキュリティは、関係なく常に伝播さConfigureAwaitれます。これは、考えてみれば理にかなっています。文化についてはよくわかりませんが、それが常に伝播されていたとしても驚かないでしょう.

于 2012-04-04T13:46:04.860 に答える