CancellationTokenSource tiene un miembro TryReset() . La documentación parece tan estricta que me hace preguntarme por qué existe.
Cancel() en él. Entonces, ¿por qué la gente se molestaría con TryReset ? ¿Por qué no simplemente crear un CancellationTokenSource completamente nuevo para cada operación asíncrona y luego desecharlo después de que se complete la operación y ya no sea necesaria la cancelación? ¿Es CancellationTokenSource un objeto terriblemente costoso de crear?
Permítanme citar aquí la sección de antecedentes y motivaciones del número.
Cuando una biblioteca o marco expone un
CancellationTokenque generalmente no se cancela (por ejemplo,HttpContext.RequestAborted), a menudo aún necesitan eliminar elCancellationTokenSource(CTS) de respaldo después de que se completa una operación en lugar de reutilizarlo para tener en cuenta a las personas que llaman que quizás nunca eliminen sus registros.Para usar el ejemplo de
RequestAborted, Kestrel desecha el CTS de respaldo después de cada solicitud en la que se accede al token deRequestAborted. Si Kestrel intentara reutilizar el CTS que respalda el tokenRequestAbortedpara futuras solicitudes a fin de reducir las asignaciones, correría el riesgo de filtrar los registros no eliminados y activar los registros no eliminados cuando se cancelan las solicitudes no relacionadas.Otro escenario en el que la gente quiere poder "restablecer" un CTS es después de llamar a
CancelAfter(). Esto ya se puede lograr llamando aCancelAfter(Timeout.Infinite), pero eso no es necesariamente obvio a menos que lea los documentos.TryReset()es algo que inmediatamente tendría sentido en este escenario al observar las finalizaciones inteligentes.Otro beneficio es que es inmediatamente obvio si falla el restablecimiento. Si intenta restablecer un tiempo de espera con
CancelAfter(), debe verificar después de la llamada para verificar que no hubo cancelación antes o durante la llamada, lo que provocó queCancelAfter()no funcionara. Esto se demuestra en el segundo ejemplo de uso deHttpClient.