我对TaskCompletionSource<>.

使用 创建简单Task<>时Factory，我希望此任务在线程池中排队，除非我指定TaskCreationOptions.LongRunning，否则它将在新线程中运行。

我对 的理解TaskCompletionSource是，我负责在任务结束或失败时触发，并且我可以完全控制如何管理线程。但是， ctorTaskCompletionSource允许我指定 a TaskCreationOptions，这让我感到困惑，因为我期待Scheduler无法处理任务本身。

TaskCreationOptions在 a 的上下文中的目的是TaskCompletionSource<>什么？

这是一个使用示例：

AFAIK，它所知道的是，在某个时候，它的SetResultorSetException方法被调用以完成Task<T>通过其Task属性公开的操作。

换句话说，它充当 aTask<TResult>及其完成的生产者。

我在这里看到了这个例子：

如果我需要一种方法来Func<T>异步执行 a 并有 aTask<T> 来表示该操作。

如果我没有，可以使用它Task.Factory.StartNew- 但我确实有Task.Factory.StartNew。

问题：

有人可以举例说明一个与我没有的假设情况直接相关TaskCompletionSource 而不是与我没有 的假设Task.Factory.StartNew情况相关的场景吗？

我有一个 WebClient (WP8) 的扩展方法

以及对该方法的调用

DownloadStringCompleted 永远不会执行，显然没有结果，如果我按下 VS 上的暂停按钮总是在 task.Result 中等待。

任何想法？

提前致谢。

我有一个黑盒对象，它公开了一个启动异步操作的方法，并且在操作完成时触发了一个事件。我已经使用 TaskCompletionSource 将其包装到一个Task<OpResult> BlackBoxOperationAysnc()方法中——效果很好。

但是，在该异步包装器中，如果在给定超时后未收到事件，我想管理完成异步调用并出现超时错误。目前我用计时器管理它：

这是管理超时的唯一方法吗？有没有设置我自己的计时器的方法 - 我看不到TaskCompletionSource中内置的任何超时？

我有一个方法是这样的：

不过，对于我的 API，我需要提供一个同步替代方案。因此，我需要一个可以等到发出信号，但可以携带一个物体的物体。AutoResetEvent 几乎符合我的标准，这就是我到目前为止所得到的：

但是，我需要得到结果。我看不出有办法做到这一点。我想过做一个EventWaitHandle衍生品，但代码隐藏看起来很奇怪，所以我不能相信它。谁能想到一种方法来做到这一点？

在我的 MVC 4 应用程序的一个操作中，我有一个电话：

DownloadAsync返回一个任务，我希望看到DownloadAsync在后台运行。但我总是看到 MVC 仅在TaskofDownloadAsync完成时响应（意味着需要等待下载完成才能响应）。如果我将异步调用包装在Task.Run()orTask.Factory.StartNew()中，那么它就像我的期望一样工作。这是方法DownloadAsync：

所以我的问题是：

1. 在这种情况下，为什么 MVC 请求需要等待完成任务？Taskcreated by有什么特别的TaskCompletionSource<T>吗？

2. 如何使TaskofDownloadAsync在后台运行而不暂停 MVC 请求的响应？

谢谢，

功能和含义有什么区别

TaskCompletionSource + SetResult vs Task + FromResult

在 SendAsync 方法中？

在我的 .NET 4.0 库中，我有一段代码通过网络发送数据并等待响应。为了不阻塞调用代码，该方法返回一个Task<T>在收到响应时完成的，以便代码可以像这样调用该方法：

底层代码使用TaskCompletionSource以便它可以等待响应消息，而不必启动线程只是让它闲置在那里直到响应到来：

收到响应后，将按如下方式处理：

现在我想添加一个超时，这样调用代码就不会无限期地等待响应。但是在 .NET 4.0 上这有点混乱，因为没有简单的方法可以让任务超时。所以我想知道 Rx 是否能够更容易地做到这一点。所以我想出了以下内容：

这一切似乎都没有问题，但是我已经看到几个问题表明Subject应该避免，所以现在我想知道是否有更多的 Rx-y 方法来实现我的目标。

我发现如果不检查特定任务或委托背后的来源，我无法区分受控/合作与“不受控制”取消任务/委托。

具体来说，我一直假设当OperationCanceledException从“较低级别的操作”中捕获抛出时，如果引用的令牌无法与当前操作的令牌匹配，那么它应该被解释为失败/错误。这是它放弃（退出）的“较低级别操作”的声明，但不是因为您要求它这样做。

不幸的是，TaskCompletionSource不能将 aCancellationToken作为取消的原因。因此，任何不受内置调度程序支持的任务都无法传达其取消的原因，并且可能会将协作取消误报为错误。

更新：从 .NET 4.6 开始，TaskCompletionSource可以关联 aCancellationToken 如果新的重载为SetCanceledorTrySetCanceled被使用。

例如以下

即使通过分发给所有组件的取消令牌请求取消，也会导致“错误：意外取消”。

核心问题是TaskCompletionSource不知道CancellationToken，但是如果用于在Tasks中包装异步操作的“转到”机制无法跟踪这一点，那么我认为人们不能指望它会被跨接口跟踪（图书馆）边界。

事实上 TaskCompletionSource 可以处理这个，但是必要的 TrySetCanceled 重载是内部的，所以只有 mscorlib 组件可以使用它。

那么有没有人有一种模式来传达取消已跨任务和委托边界“处理”？