`CancellationTokenSource.TryReset`的用例是什么？
CancellationTokenSource有一个TryReset()成员。文档看起来太严格了，我想知道它为什么会存在。
- 只有当还没有人在上面调用
Cancel()时，它才会起作用。 - 只有在以前发出的带有令牌的异步操作完成后才能使用，这意味着(我认为)我需要保存Task对象，以跟踪它是否仍在运行
- 当其他人试图取消操作时打电话是不安全的，因为
那么为什么人们会为TryReset而烦恼呢？为什么不简单地为每个异步操作创建一个全新的CancellationTokenSource，然后在操作完成并不再需要取消后将其丢弃？创建CancellationTokenSource是一个非常昂贵的对象吗？
回答 1
Stack Overflow用户
发布于 2022-02-09 11:59:10
让我在这里引用这个问题的背景和动机部分
当库或框架公开通常不会被取消的
CancellationToken(例如HttpContext.RequestAborted)时，它们仍然需要在操作完成后释放支持CancellationTokenSource(CTS)，而不是重用它，以便说明可能永远不会释放注册的调用方。 为了使用RequestAborted示例，Kestrel在访问RequestAborted令牌的每个请求之后都会处理支持CTS。如果Kestrel试图为将来的请求重用支持RequestAborted令牌的CTS，以减少分配，则可能泄漏任何未处理的注册，并在不相关的请求中止时触发未处理的注册。 人们希望能够“重置”一个CTS的另一个场景是在调用CancelAfter()之后。这可以通过调用CancelAfter(Timeout.Infinite)来实现，但除非您阅读了文档，否则这并不一定显而易见。在这个场景中，当查看intellisense完成时，TryReset()会立即变得有意义。 另一个好处是，如果重置失败，它立即是显而易见的。如果您尝试用CancelAfter()重置超时，则必须在调用之后检查它们是否是在调用之前或期间取消，从而导致CancelAfter()到no。第二个HttpClient使用示例演示了这一点。
https://stackoverflow.com/questions/71042494
复制相似问题
腾讯云开发者
