Здравствуйте, MadHuman, Вы писали:


MH>такое поведение вызывает вопросы
MH>1. зачем такое дефолтное поведение в asp.net? ведь при async/await-ах и так подразумевается что после окончания ожидания управление может продолжено свободным потоком из пула.
MH>идея продолжения в исходном хуже и с точки зрения перфа — исходный поток мог уже быть назначен для выполнения другой таски и занят.

Потому что ASP.NET и IIS устроен так, что доступ к контексту запроса возможет только из одного потока. Кроме того, если, не дай бог, вы используете WebForms, то там еще и свой ЖЦ есть и асинхронные вызовы должны сихронизироваться.


MH>в asp.net так не надо, т.е. из-за частного случая сделали неудобное поведение.
Не частного. В общем случае архитектура веб-серверов такова, что каждый запрос обрабатывает выделенный поток.

MH>2. почему нет глобальной настройки? или для рутовой таски указать стратегию для вложенных await-ах?
Конечно есть, SynchronizationContext, подробнее по ссылке https://learn.microsoft.com/en-us/archive/msdn-magazine/2011/february/msdn-magazine-parallel-computing-it-s-all-about-the-synchronizationcontext

MH>3. зачем об этом думать при каждом await ? а .ConfigureAwait(false) надо вызвать при каждом во всей цепочке
Во-первых не в каждом, а только в том, для которого вызывается Wait() или Result.
Во-вторых в общем случае не надо делать sync-over-async. Это всегда признак плохого кода. Возможно не вашего, но все равно плохого.

MH>это какое-то неудачно решение дизайна?
Очень удачное

MH>или есть какие-то причины которые от меня ускользнули?
Конечно. Вообще наивно думать, что Microsoft за 10 лет не вылизал до идеала с точки зрения дизайна и быстродействия всю систему с async\await.