我对 C# 即将推出的 async/await 功能的设计有些怀疑。
- 附加新机制的便利性
Task<T> - 我认为最好使用 async 代替 await 关键字。解释：
var result = async GetResultAsync(); - 使用令牌取消正在进行的异步操作的机制并不像我认为的那样优雅。
Async/away 是一个很棒的特性，但我认为它的设计不如 LINQ。另外，我觉得设计团队对当前的设计非常满意。并且可能不会考虑社区反馈。
你怎么看？
问问题
2091 次
4 回答
7
在您尝试自己完成这项工作之前，这些设计决策往往没有什么意义。你的任务：编写异步代码并让它随时停止。您的限制：您不能使用 Thread.Abort() 并且永远不会导致死锁。
于 2011-02-06T16:10:38.460 回答
6
Async/away 是一个很棒的特性，但我认为它的设计不如 LINQ。
与 LINQ 的设计流程相比，您觉得设计流程的哪些方面存在不足？
另外，我觉得设计团队对当前的设计非常满意。并且可能不会考虑社区反馈。
是什么给了你这样的印象？一段时间以来，我们一直在邀请社区反馈。它没有被忽视。
你怎么看？
我认为这是一个讨论问题，而不是工程问题。你确定这是这个问题的正确网站吗？
于 2011-02-06T19:28:26.080 回答
4
他们已经在
Taskand上投入了大量工作Task<T>，旨在完美适应这种情况。我觉得这很方便，因为我确切地知道对任务的期望——以前使用过它——而且我认为很多其他开发人员也会有这种感觉。在我看来，这比引入新东西要好得多——而且我什至不确定有什么不同会使新类型更能胜任这项任务。你有什么具体的想法吗？我认为您缺少
async关键字的目的。它用于标记将（部分）异步执行的方法（当您使用await关键字时）。编译器需要知道哪些方法可以“执行魔法”；它不会“转换”要异步执行的方法。为此，您应该使用ThreadPool.QueueUserWorkItem.我真的无法对此发表评论。在您看来，更优雅的解决方案是什么？如果您与他们分享，我相信 Microsoft 会考虑您的反馈。
于 2011-02-06T16:12:22.453 回答
0
于 2011-02-06T19:06:47.030 回答