`CancellationTokenSource.TryReset` 的用例是什么？

Question

CancellationTokenSource有TryReset()会员。该文档看起来如此严格，让我想知道它为什么存在。

• 只有在没有人调用Cancel()它的情况下它才会起作用。
• 仅当使用其令牌发出的任何先前异步操作已完成时才有效，这意味着（我认为）我需要挂起我的任务对象来跟踪它是否仍在运行
• 当其他人试图取消操作时调用是不安全的，需要

那么人们为什么要费心呢TryReset？为什么不简单地为每个异步操作创建一个全新的CancellationTokenSource，然后在操作完成且不再需要取消后将其丢弃？CancellationTokenSource创建一个对象是否非常昂贵？

Answer 1

• 在这里您可以找到原始问题
• 在这里您可以找到相关的拉取请求

让我在这里引用该问题的背景和动机部分

当库或框架公开CancellationToken通常不会被取消的（例如HttpContext.RequestAborted）时，它们通常仍然需要在操作完成后处置支持CancellationTokenSource（CTS），而不是重用它，以便考虑到可能永远不会处置其注册的调用者。

为了使用该示例，Kestrel 在访问令牌的RequestAborted每个请求之后都会处理后备 CTS 。RequestAborted如果 Kestrel 尝试重用支持RequestAborted未来请求的令牌的 CTS 以减少分配，则可能会泄露任何未处理的注册，并在不相关的请求中止时触发未处理的注册。

人们希望能够“重置”CTS 的另一种情况是在调用CancelAfter(). 这已经可以通过调用 来实现CancelAfter(Timeout.Infinite)，但是除非您阅读文档，否则这不一定是显而易见的。TryReset()在这种情况下，当查看智能感知完成时，这是立即有意义的。

另一个好处是，如果重置失败，立即显而易见。如果您尝试使用 重置超时CancelAfter()，则必须在调用后进行检查，以验证在调用之前或调用期间没有取消导致CancelAfter()无操作。这在第二个HttpClient使用示例中得到了演示。