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

A>Так он не параллельный, а именно последовательный! Просто в местах, где стоит await может быть перескок в другой поток. Параллельным он может быть, разве что, для вызывающего метода, если тот не делает await на нашем, когда его вызывает (но async у нашего метода как раз намекает, что такое может случится). Типичный пример:
A>...
A>Тут надо учесть, что Button_Click вернет управление сразу и нужно задизэйблить кнопку, чтоб повторный запрос нельзя было сделать — UI не блокируется же.

Лучше этот пример переписать вот так:

void async Button_Click()
{
    txt.Text=await DownloadAsync();
}

для одновременно большей красоты и непонятности (при условии, что мы хотим вообще понимать суть происходящего, а не рассчитывать на таинственную магию .net'a). Т.е. в таком коде надо чётко понимать, что между вычислением правой части (причём не важно в отдельном потоке или нет) и самим приравниванием может быть выполнен (в том же потоке) произвольный объём кода.

A>Понятно, что цикл обработки сообщений UI потока. Интересуют детали.

В каком смысле детали? ) Показать как подключаются обработчики сообщений в каком-то фреймворке или что? ) Или вытащить из исходников библиотеки код самого цикла? )

A>И без разрыва может произойти что угодно, если у нас больше одного потока. И таки код не притворяется линейным, а таким и является, до тех пор пока мы параллельность явно делать не начнем (массивы тасков с WhenAny и т.п.).

Я бы сказал что код на C# является линейным. А компилируется это (и соответственно выполняется) в совсем другие сущности. Вот эта "подделка" мне и не нравится.

Если что, это придирка не к C#, а к сопрограммам по каждому поводу вообще (т.е. включая Boost.Coroutine). Единственное отличие у C# тут в том, что в нём использование await рекомендуется везде, как повседневный инструмент. Вот это уже фигово. В C++ такого естественно нет и Boost.Coroutine используется в весьма специфических случаях, когда использование сопрограмм действительно оправдано.

A>Это правда. Для многих async означает, что при вызове метода будет делаться new Thread(...).Start() или ThreadPool.QueueWorkItem(...), а то, что до первого await код будет выполняться синхронно, не знают;
A>а await — это то, что модно писать вместо ".Wait()" в новом фреймворке. ))

A>А у меня есть подозрение, что подавляющее большинство программистов, у которых в графе профессии стоит "C++", пишут код так, что ты это, мягко говоря, не назовешь идеоматичным кодом на C++.)
A>Т.е. не только boost, но и часто STL не знают, а пишут с стиле "C++ 80х".
A>И еще подозреваю, что самый тормозной код — это код на C++, написанный "индусами".))
A>А если взять среднестатистических C++ и C# программистов, то на типичном проекте с типичными ограничениями ресурсов (время, деньги) продукт на C++ будет содержать больше багов и (о ужас!) будет тормозить, по сравнению с написанным на C#.

Ну я в общем то со всем эти согласен. Я тут уже не раз говорил, что у C++ и C# есть свои ниши, где они однозначно царят, ну и плюс большое промежуточное поле, в котором можно использовать с пользой оба инструмента. По моему мнению Java/C# отлично подходит для не IT компаний (кстати, надо понимать, что таких большинство), а соответственно C++ хорош для высокотехнологичных IT компаний, которые могут позволить себе нанимать не рядовых программистов.

_>>Нет, в boost.asio сразу много разных вариантов использования заложено. И кстати вариант на базе Boost.Coroutine вроде не так давно появился.
A>Inspired by async\await from C#?

Нуу несколько сложнее. Для начала сами Boost.Coroutine явно сделаны не под влиянием async\await, т.к. являются stackfull реализацией, а отличие от менее интересной реализации в .net. Тут прототипом скорее можно назвать какие-нибудь fibers из win32 (кстати, мы вот ещё про них забыли, когда перечисляли возможные варианты зелёных потоков). Далее, сами Coroutines появились в Boost'е относительно недавно, а Asio уже давно. Соответственно почти сразу как они появились, так и добавили в Asio вариант архитектуры с их использованием. Более того, помнится в примерах Asio давным давно встречались реализации наколенных не stackfull сопрограмм, но т.к. там всё надо было писать руками (в .net это генерирует компилятор), то особого смысла в этом не было. Т.е. там был уход от "лапши", но слишком дорогой ценой. )