Я нигде не видел этого в документах -
Если я хочу использовать CancellationTokenSource.CancelAfter(600000)
в качестве отказоустойчивого на случай, если мой вызов CancellationTokenSource.Cancel()
никогда не будет вызван.
Будет ли CancelAfter()
каким-либо образом мешать вызову Cancel()
?
Документация действительно могла бы быть более подробной по этому поводу, но .Cancel()
— это одноразовая сделка. Это означает, что любой .Cancel()
после первого ничего не делает, а .CancelAfter()
— это просто способ запланировать .Cancel()
на потом. (Согласно Стюарту, так получилось, что .CancelAfter()
на самом деле явно указывает на это является, но сам .Cancel()
нет, как и общая документация класса.)
@stuartd - я только что пропустил это предложение! Спасибо!
Нет, никаких помех. Когда CancellationTokenSource
отменяется, это атомарная операция. Либо Cancel
произойдет первым и немедленно удалит активный таймер, связанный с CancelAfter
, либо таймер будет запущен первым, а последующий Cancel
будет бездействующим.
Если хотите, можете изучить исходный код метода Cancel
здесь.
Как говорят CancelAfter документы, «По истечении миллисекундной задержки этот CancellationTokenSource отменяется, если его еще не отменили.