Боюсь таких картинок

Как огня

покажи пример как надо, я просто копипастил сам это

Убрать нечитаемые массивы и сделать обёрточку для итераций

Подниму чутка урон.

Чуть позже.

Ну вы все таки сделайте отдельный чат или в @CSharpRest переместитесь, а тот тут не все дотеры.

)(

Ты ток шо на урсе играл?

Подскажите по CancellationToken. Как с ним правильно работать, чтобы не проверять на каждом шаге IsCancellationRequested?

Можно извне отменить таск, чтобы внутри него кинулся какой-нибудь CancellationRequestedException?

По типу Thread.Abort, только для тасков

Собственно такой эксепшен уже есть: OperationCanceledException, но сейчас его руками надо кидать, либо через token.ThrowIfCancellationRequested();. А это опять, получается, надо на каждом шаге писать. Хотелось бы, чтобы шедулер автоматически это делал

Собственно такой эксепшен уже есть: OperationCanceledException, но сейчас его руками надо кидать, либо через token.ThrowIfCancellationRequested();. А это опять, получается, надо на каждом шаге писать. Хотелось бы, чтобы шедулер автоматически это делал

что-то мне подсказывает, что не получится, т.к. исключение должно быть брошено в потоке асинхронной операции, а значит этот поток должен что-то делать, например вызвать token.ThrowIfCancellationRequested();

Мне кажется, что шедулер может

Он же это делает, когда прокидывает эксепшен из дочернего таска, когда его await'ишь

Мне кажется, что шедулер может

если никакой магии нет, то шедулер не может, т.к. CancellationToken это просто объект, который никак не привязывается к потоку, а просто лежит на стеке с исключением в дочернем потоке хотя бы понятно как работает, т.к. проброска исключения мало чем отличается от проброски возвращаемого значения

Хм

Но шедулер же вроде знает о токене

Потому что он даже не запускает таск, если токен отменён заранее

То есть, грубо говоря, в момент очередного пробуждения таска, он может проверить, если токен, ассоциированный с таском, отменён, то кинуть эксепшен

Но это мои догадки, я не смотрел, как шедулер написан

Просто мне казалось, что должен быть уже готовый механизм для этого

После каждого await проверять токен, это ужасный boilerplate

насколько я помню, при запуске таска проверяется IsCancellationRequested у токена если true - таск не запускается и возвращается canceled task

вроде

Ну да, он это делает в начале таска, при запуске

Значит, наверняка может делать каждый раз, когда пробуждает таск

Это я к тому, что связь между таском и токеном где-то там хранится всё-таки

Полгода назад задался тем же вопросом, хотел найти красивое решение

Не нашёл

Это я к тому, что связь между таском и токеном где-то там хранится всё-таки

да, ты прав, токен хранится в таске https://msdn.microsoft.com/ru-ru/library/dd783029(v=vs.110).aspx

https://msdn.microsoft.com/ru-ru/library/dd321635(v=vs.110).aspx

может так попробовать?

Да, про Register я знаю

Через него как раз можно делать высвобождение ресурсов при отмене

зарегать у токена делегат на метод, внутри которого всё стопать, чистить ресурсы и бросаться CanceledException-ом

А вот прерывать выполнение руками приходится

Кто-то заблочил бота.

ЛОЛ

Да, я тоже так думал, но вроде все зарегистрированные экшены выполняются в том потоке, откуда вызван Cancel

И эксепшен соответственно тоже

А мне бы его прокинуть в continuation

Ну или хотя бы просто заставить его не вызывать этот самый continuation

Потому что всю логику по отмене можно запихать в token.Register(), а в таске надо просто return сделать

Я как-то с необходимостью такого никогда раньше не сталкивался...

обычно просто в ключевых точках IsCancellationRequested проверял

Ну да, только не в ключевых точках, а после каждого await. И если их много, то это боль, и код становится плохочитаемым

Как будто не продумали они этот механизм до конца

Как будто не продумали они этот механизм до конца

возможно у тебя кейс слишком специфический. Мне кажется что стоит отменять в первую очередь в истинно асинхронных местах: ввод/вывод. Но там и так уже есть отмена.

Есть чат, есть список диалогов

Если юзер выбирает диалог, а потом решает, что ему нужен другой диалог, а первый ещё не загрузился, в идеале задачу надо отменить и запустить новую

И вот тут такая штука бы пригодилась

возможно у тебя кейс слишком специфический. Мне кажется что стоит отменять в первую очередь в истинно асинхронных местах: ввод/вывод. Но там и так уже есть отмена.

Да вроде обычный кейс. Есть например окно, у которого очень долгая инициализация из нескольких шагов. Если окно закрыли, пока там всё грузилось, надо освободить всё, что успелось загрузиться, и не грузить дальше

Должен же быть какой-нибудь способ прибить таск

Если юзер выбирает диалог, а потом решает, что ему нужен другой диалог, а первый ещё не загрузился, в идеале задачу надо отменить и запустить новую

Вот если честно, то зачем? Это усложнение кода, которое особо ничего и недает.

Вот если честно, то зачем? Это усложнение кода, которое особо ничего и недает.

Предлагаешь оставлять то, что не догрузилось, на произвол судьбы и работать с новым инстансом окна с диалогом?

Примерно на таком вроде и остановился я в прошлый раз.

Предлагаешь оставлять то, что не догрузилось, на произвол судьбы и работать с новым инстансом окна с диалогом?

А что имеется ввиду под загрузкой?

Да вроде обычный кейс. Есть например окно, у которого очень долгая инициализация из нескольких шагов. Если окно закрыли, пока там всё грузилось, надо освободить всё, что успелось загрузиться, и не грузить дальше

Не сказал бы что это обычный кейс. Если у тебя >1 одной точки отката, то это уже сложно прописать (несколько стадий откатки). Обычно асинхронный операции содержат 1 долгую функцию или несколько мутирований засунутых в транзакцию.

Предлагаешь оставлять то, что не догрузилось, на произвол судьбы и работать с новым инстансом окна с диалогом?

Да так все и делают обычно, если операция индемпотентная.

Вообще обычное использование токена это в безопасный момент проверять его и бросать экзепшн, по другому никак не сделать

Ну сейчас примерно вот так получается: { try { var resource1 = await Load1(); token.ThrowIfCancellationRequested(); var resource2 = await Load2(); token.ThrowIfCancellationRequested(); var resource3 = await Load3(); token.ThrowIfCancellationRequested(); } catch (OperationCanceledException) { if (resource1 != null) resource1.Dispose(); if (resource2 != null) resource2.Dispose(); if (resource3 != null) resource3.Dispose(); throw; } }

ВASP.NET MVC не используется по умолчанию EF?

ERROR: S client not available

Кароч, релиз откладывается.

Мне кажется логичным, что OperationCanceledException может и сам шедулер кидать, вместо меня

Проблемы с хостингом. ?

Ну сейчас примерно вот так получается: { try { var resource1 = await Load1(); token.ThrowIfCancellationRequested(); var resource2 = await Load2(); token.ThrowIfCancellationRequested(); var resource3 = await Load3(); token.ThrowIfCancellationRequested(); } catch (OperationCanceledException) { if (resource1 != null) resource1.Dispose(); if (resource2 != null) resource2.Dispose(); if (resource3 != null) resource3.Dispose(); throw; } }

Это не очень, надо в каждый из твоих методов load передать этот токен

Это не очень, надо в каждый из твоих методов load передать этот токен

Это ничего не меняет

Это ничего не меняет

Как это не меняет?

Всё равно же придётся ThrowIfCancellationRequested вызывать

Проблемы с хостингом. ?

А был бы докер контейнер, смог бы менять хостинги на раз два. Деплой на чистый сервак за 1 минуту + 2 установка докера.

И сделать объект, в котором этот код написан idisposable и освобождать ресурсы в одном месте

Вот так тогда будет: { try { var resource1 = await Load1(token); token.ThrowIfCancellationRequested(); var resource2 = await Load2(token); token.ThrowIfCancellationRequested(); var resource3 = await Load3(token); token.ThrowIfCancellationRequested(); } catch (OperationCanceledException) { if (resource1 != null) resource1.Dispose(); if (resource2 != null) resource2.Dispose(); if (resource3 != null) resource3.Dispose(); throw; } }

При ошибке и при окончании использования этого объекта

Вот так тогда будет: { try { var resource1 = await Load1(token); token.ThrowIfCancellationRequested(); var resource2 = await Load2(token); token.ThrowIfCancellationRequested(); var resource3 = await Load3(token); token.ThrowIfCancellationRequested(); } catch (OperationCanceledException) { if (resource1 != null) resource1.Dispose(); if (resource2 != null) resource2.Dispose(); if (resource3 != null) resource3.Dispose(); throw; } }

resource1?.Dispose()

Кстати, хорошая идея с подсунуть CancellationToken в долгие таски и обрабатывать их на месте, а не уровнем выше.

resource1?.Dispose()

Ну да, это мелочи

Третье не надо писать token.throw... сам метод бросит его

Так прикол в том, что мне надо освободить ресурсы уже успешно завершившихся подтасков

HttpClient же принимает такие токены, как и многие другие таски из апи.

Например.

Так прикол в том, что мне надо освободить ресурсы уже успешно завершившихся подтасков

А у тебя есть метод dispose ?

Так прикол в том, что мне надо освободить ресурсы уже успешно завершившихся подтасков

Как ты освобождаешься ресурсы когда этот объект уже не нужен?

Вызываю Dispose

Это вот то, что внутри catch

Дак на кой тебе их освобождать тут?

А где?

В dispose методе объекта, где это код написан

Вот так тогда будет: { try { var resource1 = await Load1(token); token.ThrowIfCancellationRequested(); var resource2 = await Load2(token); token.ThrowIfCancellationRequested(); var resource3 = await Load3(token); token.ThrowIfCancellationRequested(); } catch (OperationCanceledException) { if (resource1 != null) resource1.Dispose(); if (resource2 != null) resource2.Dispose(); if (resource3 != null) resource3.Dispose(); throw; } }

А что бы не сделать обертку? class TaskCollectionExecutor<T:Task,IDisposable> { public TaskCollectionExecutor(params T tasks) { } public Awaiter GetAwaiter(){} }

В dispose методе объекта, где это код написан

Ну вообще да, согласен

В общем вопрос то и не стоит, где их освобождать

Вопрос в том, как сделать, чтобы не проверять отмену после каждого шага

Вопрос в том, как сделать, чтобы не проверять отмену после каждого шага

Передавать токен внутрь тасков, которые хочешь проверять же

И уже внутри них чекать отмену