механизм отмены асинхронного ожидания

Question

У меня есть вопрос о том, какой механизм для отмены текущей асинхронной операции можно использовать вместо токена отмены в контексте асинхронного ожидания / ожидания.Я уверен, что это хорошо изученное проектное решение, которое учитывает императивную природу языка, но в реальных ситуациях необходимость передавать объект отмены всем вашим асинхронным методам, по крайней мере, немного болезненна.Есть другие идеи дизайна от сообщества c #, или предложенный механизм отмены просто в порядке?Я думаю, что что-то упустил.

Answer 1

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

Однако вы можете, если хотите, просто «сдаться». Вместо того, чтобы указывать асинхронному потоку прервать обработку и очистку, просто «тайм-аут»; перестаньте ждать его завершения, отсоедините слушателей и продолжайте бежать. Когда поток в конце концов завершится, он проверит свое событие, поймет, что никто не слушает, и молча завершит работу. Плюсом является простота, однако есть много ситуаций, в которых это будет ПЛОХО:

• Если асинхронный процесс будет продолжать обработку вечно, пока вы не попросите его остановить, он будет продолжать работать в фоновом режиме, связывая ЦП и другие ресурсы, пока приложение не будет закрыто, и в этот момент поток будет уничтожен.
• Если асинхронный поток выполняет отменяемую, обратимую единицу работы, такую ​​как операция с БД, если пользователь нажимает кнопку отмены, он ожидает, что все выполненное до сих пор будет откатано. Если вы перестанете слушать и двигаться дальше, они получат то, что, по их мнению, они отменили.
• В большинстве случаев асинхронные операции включают внешние ресурсы, которые требуют времени для работы, а также требуют надлежащей очистки. Сетевые сокеты должны быть отключены, соединения с БД закрыты, файлы разблокированы и т. Д. Несмотря на то, что отказ от этого означает, что вам не нужно с этим сталкиваться, вместо того, чтобы позволить потоку завершиться нормально, обычным пользовательским опытом является то, что пользователь сыт по горло, нажал отмените, а затем повторите операцию. Это означает, что ресурс, который вы использовали в предыдущей асинхронной операции, должен быть освобожден, чтобы использовать его снова.

Answer 2

Для того чтобы отмена асинхронной операции имела смысл, эта операция должна выполнять дискретные шаги, поскольку она выполняет операцию проверки токена отмены и прекращает свое продолжение. То есть токен отмены - это просто шаблон для реализации, а не механизм async / await.

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

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