問題タブ [taskcompletionsource]

の内部動作について、私には不明確なことがありTaskCompletionSource<>ます。

Task<>を使用して単純なものを作成する場合Factory、指定しない限り、このタスクはスレッドプールにエンキューされることを期待します。指定しない限り、TaskCreationOptions.LongRunning代わりに新しいスレッドで実行されます。

私の理解でTaskCompletionSourceは、タスクが終了または失敗したときにトリガーする責任があり、スレッドの管理方法を完全に制御できます。ただし、のctorを使用すると、TaskCompletionSourceを指定できます。これは、タスク自体を処理できないことTaskCreationOptionsを期待していたため、混乱します。Scheduler

TaskCreationOptionsの文脈での目的は何TaskCompletionSource<>ですか？

使用例を次に示します。

AFAIK、それが知っているのは、ある時点で、そのSetResultまたはSetExceptionメソッドが呼び出されて、そのプロパティTask<T>を介して公開を完了することです。Task

言い換えれば、それはaTask<TResult>とその完成のプロデューサーとして機能します。

私はここで例を見ました：

Func<T>非同期で実行する方法が必要で、Task<T> その操作を表す方法が必要な場合。

私が持っていなかった場合に使用できますTask.Factory.StartNew-しかし、私は持っていますTask.Factory.StartNew。

質問：

誰かが、私が持っていない架空の状況に 直接関連するシナリオを例として説明できますか？TaskCompletionSourceTask.Factory.StartNew

非同期操作を開始するメソッドを公開するブラックボックス オブジェクトがあり、操作が完了するとイベントが発生します。私はそれTask<OpResult> BlackBoxOperationAysnc()を TaskCompletionSource を使用してメソッドにラップしました - それはうまくいきます。

ただし、その非同期ラッパーでは、指定されたタイムアウト後にイベントが受信されない場合、タイムアウトエラーで非同期呼び出しを完了することを管理したいと考えています。現在、次のようにタイマーで管理しています。

それがタイムアウトを管理する唯一の方法ですか? 自分のタイマーを設定せずに何らかの方法がありますか - TaskCompletionSource にタイムアウトが組み込まれているのが見えませんか?

次のような方法があります。

ただし、私の API では、同期的な代替手段を提供する必要があります。したがって、信号が送られるまで待機できるオブジェクトが必要ですが、オブジェクトを運ぶことができます。AutoResetEvent は私の基準をほぼ満たしています。これは私がこれまでに得たものです:

ただし、結果を取得する必要があります。これを行う方法がわかりません。派生物を作ろうと思ったのですEventWaitHandleが、コードビハインドが明らかに奇妙に見えたので、信用できませんでした。誰でもこれを行う方法を考えることができますか?

の機能と意味に関する違いは何ですか

TaskCompletionSource + SetResult vs Task + FromResult

SendAsync メソッドで?

私の .NET 4.0 ライブラリには、ネットワーク経由でデータを送信し、応答を待つコードがあります。呼び出し元のコードをブロックしないために、メソッドはTask<T>、応答を受信したときに完了する を返します。これにより、コードは次のようにメソッドを呼び出すことができます。

基になるコードはTaskCompletionSourceを使用して、スレッドをスピンアップせずに応答メッセージを待機できるようにします。

応答が受信されると、次のように処理されます。

ここで、タイムアウトを追加して、呼び出し元のコードが応答を無期限に待機しないようにします。ただし、タスクをタイムアウトする簡単な方法がないため、.NET 4.0 ではやや面倒です。そこで、Rx ならもっと簡単にできるのではないかと考えていました。だから私は次のことを思いついた：

これはすべて問題なく機能しているように見えますが、避けるSubjectべきであるという質問をいくつか見たので、目標を達成するための Rx-y の方法がもっとあるかどうか疑問に思っています。

特定のタスクまたはデリゲートの背後にあるソースを確認せずに、タスク/デリゲートの「制御されていない」キャンセルと制御/協調を区別できないことがわかりました。

OperationCanceledException具体的には、「下位レベルの操作」からスローされたものをキャッチするときに、参照されたトークンが現在の操作のトークンと一致しない場合、それは失敗/エラーとして解釈されるべきであると常に想定してきました。これは、あきらめた（終了した）という「下位レベルの操作」からの声明ですが、あなたがそうするように頼んだからではありません。

残念ながら、キャンセルの理由としてTaskCompletionSourcea を関連付けることはできません。CancellationTokenそのため、組み込みのスケジューラによってサポートされていないタスクは、キャンセルの理由を伝えることができず、協調的なキャンセルをエラーとして誤って報告する可能性があります。

更新: .NET 4.6 の時点で、TaskCompletionSourceは、またはの新しいオーバーロードが使用されている場合に関連付けることができます。CancellationToken SetCanceledTrySetCanceled

たとえば、次の

すべてのコンポーネントに配布されたキャンセル トークンを介してキャンセルが要求された場合でも、"エラー: 予期しないキャンセル" が発生します。

主な問題は、TaskCompletionSource が CancellationToken を認識していないことですが、非同期操作を Tasks でラップするための「go to」メカニズムがこれを追跡できない場合、インターフェイス全体で追跡されることを期待できないと思います(ライブラリ) 境界。

実際、TaskCompletionSource はこれを処理できますが、必要な TrySetCanceled オーバーロードは内部であるため、mscorlib コンポーネントのみが使用できます。

キャンセルがタスクとデリゲートの境界を越えて「処理」されたことを伝えるパターンを持っている人はいますか?