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

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

Понятно, что наличие ключевого слова await позволяет, допустим, собрать все вызовы в коллекцию и эвейтить её, или даже вообще не эвейтить, а выполнить без ожидания, или вернуть awaitable результат (Task, promise, etc.), но для подобного, более редкого, употребления можно было сделать специальный синтаксис.

MasterZivТебе вообще зачем __асинхронный__ вызов нужен?
Наверное, чтобы он выполнялся параллельно с остальным кодом...
А как оно будет выполняться параллельно, если ты тут же будешь ждать результат асинхнонного вызова?

Похоже, вы очень сильно путаете понятия.
Вот вам ссылка почитать

Вкратце, асинхронный вызов мне нужен, чтобы I/O операции не блокировали рабочий поток из пула. Запуск подобного ожидания в параллельном потоке, это костыль, не решающий проблемы, но позволяющий, например, не блокировать единственный UI поток. В контексте серверных веб-приложений, подобный финт ушами вообще бесмысленнен. А в контексте, например, JavaScript и вовсе невозможен (не будем брать в расчёт не так давно появившиеся Web Workers).

В общем, вернёмся к вопросу. Уточню, откуда ноги растут у вопроса. Проблемы две:

1. избыточность повсеместного ключевого слова await, если есть какое-то подозрение, что код модуля будет исполнять асинхронные методы, он тоже должен быть асинхронным.

2. забыли await, получили проблемы, особенно, если мы не ожидаем результат, а только сам факт асинхронного исполнения (async void).

LR


Это очень странный код, поясните, зачем вы используете здесь ContinueWith вместе с await?




По поводу второго "не нужно". Это распространённая ошибка. Если приложение нормально завершит свою работу раньше, чем ваш Task, то работа может быть прервана на середине и код в ContinueWith вообще не выполнится. И без await контекст синхронизации нужно передавать вручную (актуально для UI и для ASP.NET, но не Core).

WebSharperТогда после введения этой особенности получилось бы нарушение обратной совместимости. До нее тот же самый код бы просто запускал метод. А после нее эвейтил бы таску.

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

WebSharperПричем в документации бы пришлось писать что var x = y() ведёт себя по разному для методов возвращающих такску и прочие типы

Если бы async был частью контракта, а не реализации, то компилятор бы скрывал таску, y() при этом возвращал результат функции, а не awaitable объект в контексте использования. Проблема в том, что возвращаемый результат типа Task ещё не говорит о том, что это асинхронный метод.

LRЭто не ошибка, так задумано, если задание не выполнится до окончания работы приложения - это нормально, иначе задумано с sometask. Повторю, ситуации могут быть разными, await дает еще одну степень свободы - и это хорошо.

Спорить не буду. Лично я считаю, что запуск задач по принципу fire and forget должен осуществляться через планировщик заданий, и нормальное завершение программы не должно осуществляться путём terminate запущенных потоков. Либо нужно дожидаться выполнения всех заданий, либо посылать сигнал с требованием немедленного завершения работ, как минимум через CancellationToken, если мы говорим про C#.

Так что это выглядит как ошибка и никак иначе.

LRПовторю, ситуации могут быть разными, await дает еще одну степень свободы - и это хорошо.

Проблема в том, что "ещё одна степень свободы" выливается в описанные выше мною проблемы.

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

Если мы говорим про C#, это довольно смелое утверждение насчёт "просто вызывает методы ожидания". Я спорил с Джоном Скитом на тему является ли await синтаксическим сахаром, и он меня убедил, что да, является. Но await принуждает компилятор строить конечный автомат без накладных расходов на количество кода в продолжении. А также разбирается с исключениями и контекстом синхронизации.

В JavaScript да, это сахар, превращающийся в промисы.

Конечно, из-за отсутствия контракта, компилятор не может сам сделать await , значит при его наличии, это можно было сделать, так?

kealon(Ruslan)а как тогда должен себя вести код генерируемый компилятором?

Он должен увидеть вызов асинхронного метода и выполнить его асинхронно, и не позволять дёргать асинхронные методы за пределами асинхронного контекста (асинхронного метода).

kealon(Ruslan)всегда ждать завершения? тогда 21619662 вполне уместен

Я не понимаю, почему до сих пор много людей путают конкурентность и асинхронность. Нет, не уместен.

Давайте напомню, в JavaScript нельзя выполнить код параллельно. Можно выполнить

.. можно выполнить код асинхронно.

kealon(Ruslan)запоминать что переменная не переменная и её нужно проверять? тогда встаёт вопрос эффективности, фактически придётся делать ленивый вызов при использовании переменной, следить за ней, что в массовом порядке накладно.

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

WebSharper https://softwareengineering.stackexchange.com/questions/328087/why-are-promises-not-awaited-by-default

SONote that a function being async doesn't turn it into something completely different, it just enables some syntax. A normal function returning a promise is just as asynchronous as a function marked with async.

The await serves as a warning sign "the world may have changed in the mean time".

1. await may be easier than multi threading, but it's still very error prone. During code review you have to look at each await, thinking "does the function rely on any information obtained before the await still being the same? Is this guaranteed?". Without an explicit await, you have to do so at every function invocation.

2. Backwards compatibility. With your proposal code behaves completely different if the browse/runtime supports awaiting or not.

3. If your code doesn't want to deal with awaiting, it needs to insert an async at every call to an externally defined function, just in case it returns a promise.

4. Performance. The runtime needs to insert an if result is a promise then await check at every method call.



Ok.

1. мы хотим видеть вызовы await в коде, но IDE мог бы подсвечивать, находить и показывать такие вызовы.
2. обратная совместимость, аргумент. ок.
3. если я не хочу эвейтить, то для этого нужен отдельный синтаксис, потому что в 90% (если не больше) случаев нужно эвейтить.
4. только для нетипизированных языков, таких как JavaScript, это является проблемой. но и она решается точно также, как решаются все остальные проблемы отсутствия типизации.

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

kealon(Ruslan)собственно await это такой сахар который одновременно ждёт вычисления IASync<T> и мониторит не отменили ли головной метод и если отменили "трубит" полученному контракту "СТОП"

Ничего он не мониторит, а сигнализацию прерывания надо пробрасывать самому.

Сахар превращает метод в конечный автомат. Это можно посмотреть в дизассемблере IL, для асинхронного и синхронного вызовов. С ручным ожиданием через GetAwaiter и через await. Сгенерированный код будет абсолютно разный.

kealon(Ruslan)как это всё выглядит изнутри плюсов:
вызвали аснхронный метод, собственно он возвращает контракт IASync<T>
и тут можно с ним делать что угодно: подождать вызвать другой метод и пр.


как это может быть в плане реализации асинхронного метода:
тут куча вариантов: асинхронная функция ОС, запуск обёрнутой задачи в пул и пр. пр.


Из плюсов, да и в C# тоже, весь код, который генерит await можно написать и самостоятельно. Чудеса начинаются, когда среди кучи последовательных и вложенных await доходим до функций, выполняющих непосредственно I/O операции, которые и "отпускают" поток восвоясь. А когда результат будет получен, будет выдернут любой свободный поток, который продолжит выполнение оставшегося кода. Вот здесь суть, которую многие упускают, когда пытаются "на пальцах" строить свои объяснения того, как это устроено. Это и правда выглядит так, как будто оставшийся кусок метода после await тупо завернули в коллбек. Но это наивно так полагать.

kealon(Ruslan)hVosttНо await принуждает компилятор строить конечный автомат без накладных расходов на количество кода в продолжении. А также разбирается с исключениями и контекстом синхронизации.ничего он не выдумывает, он просто вставляет код ожидания

Куда вставляет? Кто код ожидания будет выполнять? Что там со стеком? Могу ли я ожидать огромное количество асинхронных операций, с небольшим количеством рабочих потоков?

kealon(Ruslan)у него только контракт (IASync<T>) и есть, он и вызывает один из его методов, на саму реализацию он не влияет

Пока нет такого контракта, который напрямую говорит, что этот метод является асинхронным. Для await подойдёт любой объект, у которого есть метод GetWaiter(). Этого недостаточно, так как те же Task используются и для многопоточного программирования, как часть TPL.


kealon(Ruslan)ему вообще по барабану, у компилятора только контракт на ожидание выполнения непонятно чего




куда физически вставлять await?

Вот сюда. И только при условии, что метод, в котором находится этот код помечен как async.

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

Т.е. будете ждать выполнение i/o операций на выделенном пуле потоков? Мдя...

Valery_BЕсли я правильно понял, то ты хотел предложить не использовать await ?

Не использовать ключевое слово await, в контексте, где его использование очевидно. Такой контекст есть.


Valery_B


Первый случай это запуск таски в отдельном потоке, последующий await приводит только к асинхронному ожиданию (о чём было сказано 21619662 ), а не асинхронному выполнению.

Во втором случае, функция помечена async , значит вызов любой асинхронной функции должен быть асинхронным, если это не указано каким-то определённым образом иначе.

kealon(Ruslan)не выдумывайте, там обычный линейный код

Да, там код. Это правда

kealon(Ruslan)ожидание выполняет реализатор контракта IAsync<T>
в частности с IO, для этого достаточно текущую нить отдать "планировщику" и переключиться на выполнение другой задачи.

Вы не хотите разбираться как работает паттерн async/await, вообразили себе как он работает примитивным образом, окей. Спорить не буду, топик не об этом.

Мне-то что хотите доказать? Я вопрос и проблемы в начале топика озвучил. Они не критичные, но с ними пришлось столкнуться.

Valery_BДля меня как раз наоборот - первый случай абсолютно очевиден, а второй - наоборот.
Не понятно, что должна сделать эта процедура выполняя первый и второй оператор.
И в каком потоке.




Это потому что вам это ещё пока не привычно.

Посмотрите, что случилось, когда в Java ввели var , сколько воя и боли.
Очевидно, что это упрощает написание и облегчает код, но некоторые сразу сказали, что им непонятно теперь какого типа переменные, var всё портит

Здесь ситуация такая же. Мне достаточно, если асинхронные методы будут иметь суффикс Async, ну и IDE мог бы с лёгкостью подсвечивать асинхронные вызовы.

Просто этого нет пока, надо вручную писать много await и это печалит.

kealon(Ruslan)на дуболомный вопрос MasterZiv-а у вас нет ответа

Если вы не разбираетесь в вопросе вместе с MasterZiv, в этом ничего плохого нет, не нужно вступать в полемику.


kealon(Ruslan)а конкретно если у вас везде await, то что-то с вашим кодом не так

по вашему




должен преобразоваться в



Мда.

ViPRoshVostt,

че то ты где то не понял :(
async await {censored} не нужны

В контексте твоих проектов, не особо нужны.

ВМоисеев<На первый взгляд неплохо - меньше писанины. Но мне приходится писать и так:



Но это не асинхронный вызов. Это асинхронное ожидание, в этом случае блокируется отдельно выделенный поток для абсолютно синхронного выполнения i/o операции.

LRМдя)) Почитать документацию и узнать что такое async-методы не судьба, я так понимаю...\

Судя по наивным и глупым мессаджам kealon(Ruslan) , это вообще тёмный лес.

Я понимаю, даже не удосужился почитать, не имел дела, да и понятия не имеет о чём идёт речь, но своё однозначное мнение имеет

ВМоисеевНазывайте как хотите, но вторя Вам - асинхронный вызов мне нужен, чтобы I/O операции не блокировали UI поток.

Это можно сделать и без await. Это делали 10 лет назад в тех же винформсах. Поэтому это за рамками топика.


ВМоисеевИспользуемая конструкция реализует асинхронность(параллельность) выполнения I/O.

Нет, I/O здесь выполняется синхронно, в синхронном коде. Вы просто реализуете асинхронное ожидание результата. Но если так нравится, используйте ради бога, но это немного за рамками топике.

kealon(Ruslan)направление мыслей уже правильное
глядишь уже сможешь понять 21619662

Вот эти глупости может прекратите копипастить?

Dima TТам слишком глубокий вопрос. В C# все прозаически банально: async/await надо для отзывчивости гуя. Чтобы клик по кнопке не завесил прогу. По встрече await дальнейший код уходит в другой поток, освобождается поток обработки сообщений, тот принимает следующее сообщение виндовса и т.д. Плюсом await дает написать хорошо читаемый код, т.е. синтаксический сахар в чистом виде.

В остальном от async/await пользы не много. Я консольные утилиты пишу, хотел поюзать async/await, но не придумал где, зато пришлось наоборот поискать как синхронно запустить xxxAsync().

У вас что, патологическая неприязнь к литературе, к справочным материалам? Вы хотя бы почитайте на оф. сайте, я уж не говорю о какой-либо практике.

Прозаически банально это в вашем воображении. Нет, async/await нужен вовсе не только для отзывчивости гуя, это прекрасно решали ещё 10 лет назад, существует как минимум 2 асинхронных API, до появления TAP. Но я сомневаюсь, что вы о них вообще слышали.

Dima TЯ консольные утилиты пишу, хотел поюзать async/await, но не придумал где, зато пришлось наоборот поискать как синхронно запустить xxxAsync().

Ну ясно. Если практика этим заканчивается, async/await вообще здесь не к месту.

LRеще раз (а лучше два или три) перечитываем (эту гребаную) документацию
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/await An await expression does not block the thread on which it is executing...
и думаем...думаем...думаем...

Это бессмысленно. Если человек себе что-то в голову вбил, и забил на документацию, это бессмысленно.

Я честно говоря, вообще в глубоком шоке.
Не думал, что придётся столкнуться с подобным невежеством.