Комментарии 10
Важно отметить, что
CancellationTokenиCancellationTokenSourceреализованы как структуры(struct)
CancellationTokenSource не структура, это класс.
В структуре данные хранятся в стеке, в отличие от классов, которые хранятся в куче.
Это слишком грубое упрощение. Более правильное другое - память для структур (или Value type), выделяется прямо в месте, где она используется (да, часто это стек), память для классов (или Reference type), выделяется где-то еще, а в месте использования, присутствует лишь ссылка на выделенную в другом месте память.
К вашему утверждению можно с ходу задать вопрос - а где хранятся данные для, скажем, каждой из структур, из массива в 1 млн. структур ну или даже в 10 млн.? В стек такое явно не влезет
if (cancellationToken.IsCancellationRequested)
cancellationToken.ThrowIfCancellationRequested();Вам не показалось, что if тут явно избыточен?
А где, собственно, погружение-то?
CancellationTokenSource cts = new();
CancellationTokenSource он IDisposable, его бы лучше с using использовать иль в finally "диспоузить". Еще можно добавить про то, что если реакция на CancellationToken в пользовательской логике никак не реализована, то соответственно ничего и не произойдет.
CancellationToken в C# реализуется через два основных класса: CancellationToken и CancellationTokenSource.
Важно отметить, что CancellationToken и CancellationTokenSource реализованы как структуры (struct)
Это в рамках одного монитора написано, и при этом, оба высказывания ложны
Приведено несколько примеров, но ни слова об использовании в REST API:
[HttpGet("{id:guid}")]
public async Task<Data> Get(Guid id, CancellationToken ct) =>
await service.Get(id, ct);Если пользователь закроет страницу при загрузки данных, запрос будет отменён.
Всем спасибо за замечания! Внесли изменения, теперь статья более актуальна)
Общее впечатление от статьи - заголовок не соответствует содержимому: никакого "глубокого погружения" в статье нет. А есть много фрагментарной информации, не охватывающей даже близко всю тематику. Например про CancellationToken/CancellationTokenSource не сказано о связанных (linked) CancellationToken, о регистрациях функций обратного вызова при отмене, об использовании CancellationToken как события (например, свойства интерфейса IHostApplicationLifetime в статьях часто называют событиями, а их тип - тот самый CancellationToken), о необходимости очистки (Dispose) CancellationTokenSource, об особенностях работы с ним после очистки. А в теме про ASP.NET Core нет ничего про CanclellationToken определенных в нем (напрмер, свойстве HttpContext.RequestAborted) и в связанных с ним сервисах (наприме, свойства уже упомянутого IHostApplicationLifetime). Раздел про шаблоны ("паттерны") проектирования вообще выглядит каким-то посторонним.
Короче, статья содержит довольно бессистемно выбранный набор сведений на тему CancellationToken. Может, кому-то что-то из этих сведений будет полезным, но лично мне под заголовком "глубокое погружение" хотелось бы увидеть что-то большее.
PS И ещё: обычный (в документации MS, в переводах базовых книг по .NET типа той, что от Дж.Рихтера) перевод для сочетания cooperative cancellation - это "скоординированная отмена". А не "кооперативная" (к чему у человека моего поколения сразу в голову приходит советский синоним - "колхозная" со всеми его коннотациями).
PS И ещё: обычный (в документации MS, в переводах базовых книг по .NET типа той, что от Дж.Рихтера) перевод для сочетания cooperative cancellation - это "скоординированная отмена". А не "кооперативная" (к чему у человека моего поколения сразу в голову приходит советский синоним - "колхозная" со всеми его коннотациями).
Как по мне, так "кооперативная" понятнее:
Глубокое погружение в CancellationToken: эффективное управление отменой в .NET