为什么 TaskFactory.StartNew 方法不是通用的？

Question

在 .NET 4.0 中使用 TPL 启动新的仅副作用任务（即：不返回结果的任务）的理想方法是使用以下 API：

Task Task.Factory.StartNew(Action<object>, object)   

但是为什么此 API 的签名看起来不像这样

Task Task.Factory.StartNew<T>(Action<T>, T) 

或像这样

Task Task.Factory.StartNew<T>(T, Action<T>) 

技术原因或其他原因？

Answer 1

好吧，现在我正确理解了这个问题:)

我相信这是因为这意味着 直接替换ThreadPool.QueueUserWorkItem。我确实同意这看起来有些奇怪......但是如果你无论如何都在使用lambda表达式，那么使用确实采用状态参数的版本可能会更容易（即Action 而不是 Action

Answer 2

根据 Stephen Toub (MSFT) 的一篇文章，他们假设我们将依赖闭包来传递状态数据。还有一些关于签名歧义的借口。 （http://social.msdn。 microsoft.com/Forums/en/parallelextensions/thread/1988294c-de41-476a-a104-aa550b7409f5）

然而，依靠闭包来解决这个问题似乎是一个等待更好解决方案的临时黑客。它有效，但它不是一个好的长期解决方案。很多时候，简单地指定委托方法作为操作将是最简单的方法，但这意味着我们必须使用全局变量，否则我们将被排除在状态参数传递之外。

我喜欢 Hugo 的一项提案（来自 MS 论坛的帖子）。 Hugo 建议引入 TaskState 类型，这似乎是规避泛型歧义问题的聪明方法。

将其应用到 Task.Factory.StartNew() 签名和 Task() 构造函数，如下所示：

  public Task<T>( Action<T> function, TaskState<T> state );
  public Task<T,TResult>( Func<T,TResult> function, TaskState<T> state );

ActionState 非常类似于 Nullable 类 —— 只是 Value 成员的简单包装。实际上，使用 TaskState 可能如下所示

  var myTask = new Task( MyMethod, new TaskState( stateInfo ) );
  ...

  public void MyMethod( StateInfo stateInfo ) { ... }

：解决方案并不完美，但它似乎是比依赖类型转换闭包更好的解决方案。