c# - async/await 取消机制

Question

我有一个关于可以使用什么机制来取消正在进行的异步操作的问题，而不是 async/await 上下文中的取消令牌。我确信这是一个经过充分研究的设计决策，它考虑了语言的命令性质，但在实际情况下，必须将取消对象传递给所有异步方法，至少有点痛苦。c#社区还有另一种设计思路，还是提议的取消机制就好了？我想我错过了一些东西。

Answer 1

取消令牌是最佳实践，尤其是在异步进程成本高、没有预设结束条件或涉及外部资源的情况下。

但是，如果您愿意，您可以简单地“放弃”。而不是告诉异步线程中止处理和清理，只是“超时”；停止等待它完成，分离所有侦听器并继续运行。当线程最终完成时，它会检查它的事件，发现没有人在听，然后静默终止。好处是简单，但是在许多情况下这将是一件坏事：

• 如果异步进程将永远继续处理，除非您告诉它停止，否则它将继续在后台运行，占用 CPU 和其他资源，直到应用程序关闭，此时线程将被终止。
• 如果异步线程正在执行可中止的、可逆的工作单元（例如 DB 操作），如果用户按下取消，他们希望到目前为止所做的任何事情都已回滚。如果您停止倾听并继续前进，他们将得到的是他们认为他们取消的内容已执行。
• 在大多数情况下，异步操作涉及需要时间处理的外部资源，并且还需要适当的清理。必须断开网络套接字，关闭数据库连接，解锁文件等。虽然放弃意味着您不必处理这些，而是​​让线程正常结束，但常见的用户体验是用户厌倦了，命中取消，然后重试该操作。这意味着您在之前的异步操作中使用的资源必须被释放才能再次使用它。

Answer 2

为了使异步操作的取消有意义，该操作必须执行谨慎的步骤，因为它是检查取消令牌并停止自身继续的操作。即取消令牌只是一种要实现的模式，而不是异步/等待机制。

这意味着如果您的异步操作只是一个带有完成句柄的 I/O 调用，那么您也可以放弃而不是取消，因为在该调用返回之前，该操作将没有机会检查您的令牌在这一点上没有什么可以得到的。

因此，在考虑取消令牌时，首先要考虑是否可以通过支持取消来提高此操作的效率，或者不等待它完成（即使用超时机制代替）是否更有意义。