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

Question

CancellationTokenSource有一個TryReset()成員。 該文檔看起來如此嚴格，以至於讓我想知道它為什么存在。

• 它只有在沒有人已經調用Cancel()時才會起作用。
• 它僅在使用其令牌發出的任何先前異步操作完成時才有效，這意味着（我認為）我需要掛起我的任務 object 以跟蹤它是否仍在運行
• 當其他人試圖取消操作時調用是不安全的，需要

那么為什么人們會為TryReset而煩惱呢？ 為什么不簡單地為每個異步操作創建一個全新的CancellationTokenSource ，然后在操作完成並且不再需要取消后將其丟棄？ CancellationTokenSource是一個非常昂貴的 object 創建嗎？

Answer 1

• 在這里你可以找到原始問題
• 在這里您可以找到相關的拉取請求

讓我在這里引用問題的背景和動機部分

當一個庫或框架公開一個通常不會被取消的CancellationToken （例如HttpContext.RequestAborted ）時，他們通常仍然需要在操作完成后處理支持的CancellationTokenSource (CTS)，而不是重新使用它來考慮可能永遠不會處理的調用者他們的注冊。

要使用RequestAborted示例，Kestrel 在訪問RequestAborted令牌的每個請求之后處理支持 CTS。 如果 Kestrel 試圖為未來的請求重用支持RequestAborted令牌的 CTS 以減少分配，它可能會泄露任何未處理的注冊並在不相關的請求被中止時觸發未處理的注冊。

人們希望能夠“重置”CTS 的另一種情況是在調用CancelAfter()之后。 這已經可以通過調用CancelAfter(Timeout.Infinite)來實現，但除非您閱讀文檔，否則這不一定很明顯。 TryReset()是在查看智能感知完成時在這種情況下立即有意義的東西。

另一個好處是，如果重置失敗，它會立即顯而易見。 如果您嘗試使用CancelAfter()重置超時，您必須在調用后檢查以驗證它們在調用之前或期間沒有取消導致CancelAfter()無操作。 這在第二個HttpClient用法示例中進行了演示。