Gobzo KoblerЕсли асинхронные вызовы все равно выполнаются в текущей нитке, в чем глубокий смысл?

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

И нет, синхронный код асинхронного метода выполняется не в текущей нитке, а в первом свободном потоке (см. ConfigureAwait, чтобы этим управлять).

Gobzo KoblerРаботаю с несколькими чужими веб проектами где везде суют асинхронное исполнение. Накой? Все равно браузеру ждать ответа.

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

А «Все равно браузеру ждать ответа» это верно, быстрее работа с СУБД или файлами от этого не станет, но драгоценные ресурсы при этом экономятся. Т.е. другими словами, клиенты не ждут, когда освободится поток, который тупо ждёт когда там база данных раздуплится.

Gobzo KoblerИ чё мы выиграли?

В данном случае мы видим, что мы пишем в XmlWriter, но маленькими порциями, это не значит, что все эти операции обязательно будут I/O операциями, данные пишутся в буффер, когда буффер наполнится, он скидывается на диск, и только в этот момент происходит I/O операция, которую не хотелось бы ждать и блокировать поток. Проблема в том, что мы не знаем КОГДА этот буфер наполнится, а управлять буффером вручную не хотелось бы. Поэтому ВСЕ эти маленькие операции должны выполняться с помощью конструкций асинхронного вызова.

Фишка в том, что ты не можешь в методе, который был вызван синхронно (т.е. без await), выполнить асинхронный вызов через await когда тебе вздумается, и чтобы это имело под собой обозначенный профит. Нет, не можешь. Поэтому ВЕСЬ код, который собирается выполнять I/O операции хоть где-то, должен быть async. Конечно, ты можешь в любой момент вернуться с одной из старых моделей для асинхронных вызовов, от чего как раз все уходят. На событиях, делегатах, специальных интерфейсах :)

Модератор: Тема перенесена из форума "Программирование".

Petro123Код действительно некрасивый.
Нужно делать асинронным сам объект.

Что некрасивого? Можно прокидывать делегат с синхронным кодом внутрь асинхронного, но нафига эти костыли?

Petro123Нужно без этого слова но асинхронно.

код в студию

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

не могут, не передаётся CancellationToken

Petro123Он тот же без слов await в каждой строке.
Сам класс xmlWriter внутри накапливает в буфер и другим потоком выполняет.
Т.е. 15 строк пробегут мгновенно.
Больше ничего не надо. Всё внутри xmlWriter.

угу, вместо одного, ты два потока сожрёшь. ясно

Gobzo KoblerКакую-такую "другую работу"? Обрабатывается HTTP запрос, ему нужен XML созданный обработчиками. Что еще он может "делать" пока создается XML по кусочкам?

обрабатывать другие запросы, вот что делать.

Gobzo KoblerНе на диск, а в Response.

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

Gobzo KoblerhVostt,

ты хочешь сказать что все запросы обрабатываются одним потоком?

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