タグ付けされた質問 「async」

1
ASP.NET MVCの非同期コントローラー:真の利点/達成方法
私はASP.NET MVCの非同期コントローラーメソッドに関する記事(http://visualstudiomagazine.com/articles/2013/07/23/async-actions-in-aspnet-mvc-4.aspx)を通して取り組んできました。ポイントが足りないかもしれません。 私が書いたこの方法を考えてみましょう。これは、記事の例に非常によく似ています。 [HttpGet] [AsyncTimeout(8000)] [HandleError(ExceptionType = typeof(TimeoutException), View = "TimedOut")] public async Task<ActionResult> Index(CancellationToken cancellationToken) { WidgetPageViewModel model = new WidgetPageViewModel() { toAdd = new Widget() }; model.all = await _repo.GetAllAsync(cancellationToken); return View(model); } 私は物事を理解しているので、これは物事が実行時に展開する方法です: 着信HTTP要求に対してASP.NETスレッドが作成されます。 このスレッドは(おそらく何らかの必要な準備作業を行った上で)上記のIndex()メソッドに入ります。 実行は「await」キーワードに到達し、別のスレッドでデータ取得プロセスを開始します。 元の「ASP.NET」スレッドは、戻り値としてTaskクラスのインスタンスを使用して、ハンドラーメソッドを呼び出したコードに戻ります。 ハンドラーメソッドを呼び出したインフラストラクチャコードは、実際のActionResultオブジェクトを使用する必要があるポイントに到達するまで(ページのレンダリングなど)、元の "ASP.NET"スレッドで動作し続けます。 次に、呼び出し元はTask.Resultメンバーを使用してこのオブジェクトにアクセスします。これにより、上記の手順3で暗黙的に作成されたスレッドを待機します(つまり、「ASP.NET」スレッド)。 私が些細なことだと思う2つのことを除いて、await / asyncなしで同じことと比較してこれが何を達成するのか見ていません: 呼び出し側スレッドとawaitによって作成されたワーカースレッドは、一定の期間(上記の#5の「まで」)並行して動作できます。私の考えでは、その期間はかなり短いです。インフラストラクチャがコントローラーメソッドを呼び出す場合、それが(もしあれば)さらに多くのことができるようになる前に、通常はコントローラー呼び出しの実際のActionResultが必要だと考えています。 長時間実行される非同期コントローラー操作のタイムアウトとキャンセルに関連するいくつかの有用な新しいインフラストラクチャがあります。 非同期コントローラーメソッドを追加する目的は、ASP.NETワーカースレッドを解放して、実際にHTTP要求に応答することです。これらのスレッドは有限のリソースです。残念ながら、記事で提案されているパターンが実際にこれらのスレッドを節約するのにどのように役立つかはわかりません。そして、それが何らかの形でリクエストを処理する負担を何らかの非ASP.NETスレッドにオフロードしても、それは何を達成しますか?たまたまHTTP要求を処理できるスレッドは、一般のスレッドとは大きく異なりますか?

2
長時間実行される非同期ジョブを管理する際のベストプラクティス
私は、エンドユーザーが長時間実行される非同期処理ジョブを生成するWebページから要求を送信するプロジェクトの設計段階にいます。この問題の「ベストプラクティス」はありますか?Webサービスとサービスブローカーは良い方法ですか?Microsoftメッセージングキューはここで適用できますか?

2
スレッドがwhileループ内でタスクを待機すると、正確にはどうなりますか?
しばらくC#の非同期/待機パターンを処理した後、次のコードで何が発生するかを説明する方法が本当にわからないことに突然気づきました。 async void MyThread() { while (!_quit) { await GetWorkAsync(); } } GetWorkAsync()Task継続が実行されたときにスレッド切り替えを引き起こす場合とそうでない場合があるawaitableを返すと想定されます。 待機がループ内になかったとしても、混乱することはありません。私は当然、メソッドの残りの部分(つまり、継続)が別のスレッドで実行される可能性があることを期待しています。 ただし、ループ内では、「メソッドの残りの部分」の概念が少し曖昧になります。 スレッドが継続で切り替えられた場合と切り替えられなかった場合の「ループの残りの部分」はどうなりますか?ループの次の反復はどのスレッドで実行されますか? 私の観察では、各反復が同じスレッド(元のスレッド)で開始され、継続が別のスレッドで実行されていることが(最終的に検証されていません)示されています。これは本当にあり得ますか?はいの場合、これは、GetWorkAsyncメソッドのスレッドセーフティに対して考慮される必要があるある程度の予期しない並列処理ですか? 更新:一部の人が示唆したように、私の質問は重複ではありません。while (!_quit) { ... }コードパターンは単に私の実際のコードを簡略化したものです。実際には、私のスレッドは、定期的に(デフォルトでは5秒おきに)作業項目の入力キューを処理する長期ループです。実際の終了条件チェックも、サンプルコードで提案されている単純なフィールドチェックではなく、イベントハンドルチェックです。
10 c#  loops  async 

1
先物/モナドvsイベント
アプリケーションフレームワークで、パフォーマンスへの影響を無視できる場合(最大で1秒あたり10〜20イベント)、 モジュール間の通信の優先媒体として使用するのに、より保守的で柔軟なものは何ですか?イベントまたは先物/プロミス/モナド? イベント(pub / sub、メディエーター)は疎結合を許可するため、より保守しやすいアプリであるとよく言われます...私の経験ではこれが否定されます。20以上のイベントがあると、デバッグが困難になり、リファクタリングも行われます-誰が、いつ、なぜ使用するのかを確認するのは非常に難しいためです。 約束(私はJavascriptでコーディングしています)は、イベントよりも醜くて気難しいものです。ただし、関数呼び出し間の接続を明確に確認できるため、アプリケーションロジックがより簡単になります。私が恐れていること。ただし、Promiseはそれらとのより強い結合をもたらすでしょう... PS:答えはJSに基づく必要はありません。他の関数型言語の経験は大歓迎です。

4
継続/コールバックを読みやすいコードにするにはどうすればよいですか?
概要:非同期コードとコールバックを使用しているにもかかわらず、コードを読みやすくするために使用できる、確立されたベストプラクティスのパターンはありますか? 非同期に多くのことを行い、コールバックに大きく依存するJavaScriptライブラリを使用しています。単純な "load A、load B、..."メソッドを書くのはかなり複雑になり、このパターンを使用するのは難しいようです。 (不自然な)例を挙げましょう。リモートWebサーバーから一連の画像を(非同期で)ロードしたいとします。C#/ asyncでは、次のように記述します。 disableStartButton(); foreach (myData in myRepository) { var result = await LoadImageAsync("http://my/server/GetImage?" + myData.Id); if (result.Success) { myData.Image = result.Data; } else { write("error loading Image " + myData.Id); return; } } write("success"); enableStartButton(); コードレイアウトは「イベントのフロー」に従います。最初に、開始ボタンが無効になり、次に画像が読み込まれ(awaitUIの応答性が維持されます)、その後、開始ボタンが再び有効になります。 JavaScriptでは、コールバックを使用して、これを思いつきました: disableStartButton(); var count = myRepository.length; function loadImage(i) { …

1
C#5.0の非同期関数と通常の関数の間の線をぼかす
最近、C#5.0の驚くべき非同期待機パターンを十分に理解できていないようです。あなたは私の人生のどこにいましたか? 単純な構文には本当に感激していますが、小さな難しさがあります。私の問題は、非同期関数の宣言が通常の関数とはまったく異なるということです。他の非同期関数で待機できるのは非同期関数だけなので、古いブロックコードを非同期に移植しようとすると、変換しなければならない関数のドミノ効果があります。 人々はこれをゾンビの蔓延と呼んでいます。asyncがコードに噛み付くと、ますます大きくなります。移植プロセスは難しくありません。async宣言をスローし、戻り値をでラップするだけTask<>です。しかし、古い同期コードを移植するときに、これを何度も繰り返すのは面倒です。 両方の関数タイプ(asyncとplain old sync)がまったく同じ構文を持っていると、はるかに自然に思えます。これが事実であった場合、移植はゼロの労力で済み、2つの形式を簡単に切り替えることができます。 私はこれらのルールに従えばこれはうまくいくと思います: 非同期関数はasync宣言を必要としなくなります。それらの戻り値の型をにラップする必要はありませんTask<>。コンパイラは、コンパイル時に非同期関数を単独で識別し、必要に応じてTask <>ラッピングを自動的に実行します。 非同期関数の呼び出しを忘れることはありません。非同期関数を呼び出したい場合は、それを待つ必要があります。私はとにかくファイアアンドフォーゲットをほとんど使用していません。クレイジーレースコンディションやデッドロックのすべての例は、常にそれらに基づいているようです。私はそれらが私たちが活用しようとしている同期の考え方とあまりに混乱していて「連絡がない」と思います。 本当に忘れずに生きられないのなら、それのための特別な構文があります。いずれにせよ、それは私が話している単純な統一構文の一部にはなりません。 非同期呼び出しを示す必要がある唯一のキーワードはawaitです。待機している場合、呼び出しは非同期です。そうでない場合、呼び出しは従来の同期になります(覚えておく必要はありません)。 コンパイラーは非同期関数を自動的に識別します(関数には特別な宣言がなくなるため)。ルール4では、これを非常に簡単に行うawaitことができます。関数の内部に呼び出しがある場合、関数は非同期です。 これでうまくいきますか?または私は何かを逃していますか?この統一された構文ははるかに流動的で、ゾンビの蔓延を完全に解決できます。 いくつかの例: // assume this is an async function (has await calls inside) int CalcRemoteBalanceAsync() { ... } // assume this is a regular sync function (has no await calls inside) int CalcRemoteBalance() { ... } // …

1
インターフェースと非同期の設計
IFolderRepositoryそのようなメソッドを持つインターフェースを作成したとしましょう: IEnumerable<Folder> GetAllFolders(); Folder GetFolderWithId(int id); void AddFolder(Folder newFolder); void ModifyFolder(Folder folderToModify, Folder folderAfterModification); void RemoveFolder(Folder folderToRemove); と私は実装DatabaseFolderRepositoryして言ってみましょうCacheFolderRepositoryDecorator。ここで「数百行後」にSkyDriveフォルダーの機能を追加したいので、追加しSkyDriveFolderRepositoryます。残念ながら、DatabaseFolderRepository実装はデータベースと通信するために同期メソッドを使用していましたが、skydrive 1では多くのasyncおよびを使用していますawait。そのような場合はどうしますか?voidメソッドで非同期とマークされている場合は、解決策ではありません(例外処理が必要)。インターフェースを変更して返す必要がありますTask<T>か?確かに上記の例では機能しますが、これらは2つのインターフェース実装クラスにすぎません。それとも、ほとんどのインターフェイスにTask戻り値の型があるべきですか(規則を必要としないので)。
9 c#  async 

3
JavaScript Asynch-Loaderの選択[終了]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか? 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 私はさまざまな非同期リソースローダーを調べてきましたが、どれを使用するのかまだわかりません。私が作業している場所には、クラスモジュールが異なるバージョンのjQuery(など)を使用している可能性がある、さまざまなグループの取り組みがあります。そのため、ネストされた依存関係も異なる場合があります。私はこれを制御できないため、同じライブラリの別のバージョンを使用する可能性があるリソースを動的にロードする必要があります。 そのため、ここに私の要件があります: JavaScriptおよびCSSリソースファイルを非同期でロードします。 バージョン間の依存関係の順序とネストされた依存関係を管理します。 リソースが既にロードされているかどうかを検出します。 クロスドメインローディングを許可する必要があります(CDN) (オプション)リソースのアンロードを許可します。 私は見てきました: カール RequireJS JavaScriptMVC LABjs バージョンを適切な名前空間の変数にロードし、配列を使用して既にロードされているものを追跡することで、これらの要件を自分で偽造できるかもしれませんが、(うまくいけば)誰かがすでにこれを発明しています。 だから私の質問は: どれを使いますか?なぜ? 私の要件を完全に満たしている人は他にいますか? 雄弁で最も扱いやすいのはどれですか。なぜ? 更新: 興味のある方のために、私は上記のAMDライブラリ(すべて)をすべて試しました。結局、私はRequireJSを使いました。全体的にすっきりしていて簡単です...そして、私はそれを使用してうれしいです。

4
ページ上のREST API呼び出しが多すぎますか?
高度にモジュール化された小さなコンポーネントを使用して設計されたWebアプリ(この場合はAngularJSディレクティブを使用しますが、WebComponents、ReactJSコンポーネント、またはその他のテクノロジと同じくらい簡単にできます)。多くの場合、コンポーネントには、初期化時またはユーザーの操作時に非同期REST API呼び出しがあります。この設計により、ページごとに多くのAPI呼び出し(20以上の場合もあります)が発生しています。このデザインに問題はありますか?シングルトンとして機能するより大きなクライアント側サービスにAPI呼び出しを圧縮することを提案している人もいます。したがって、ページがそのデータの一部しか使用しない場合でも、10回のAPI呼び出しは1回に削減される可能性があります。赤い旗、またはこのデザインの問題はありますか?どちらを優先すべきですか?
8 rest  api  async 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.