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

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

A>>Что-нибудь, что позволяет выпрямить такой код:
A>>...
A>>А в идеале, чтоб, если захочется, еще можно было, например, завернуть все в try/catch:
A>>...

_>Если цель именно "выпрямлять", то по идее ничего кроме какой-то разновидности сопрограмм и не поможет. Моя же мысль была в том, что кроме "лапшевидного" и "выпрямленного" кода, могут быть и другие удобные варианты. Кроме уже упомянутых акторов можно вспомнить ещё и организацию обработки сообщений в классических ООП фреймворках (когда весь управляющий код скрыт где-то внутри, а пользователь библиотеки просто переопределяет пару нужных функций у наследуемого класса, которые будут сами вызваны фреймворком в нужный момент).
Да, но если в этих переопределенных функциях делать вызовы async IO...

_>Или например если взять машину состояний с нетривиальной реализацией (типа такого http://www.boost.org/doc/libs/1_56_0/libs/msm/doc/HTML/ch03s04.html#d0e1462 например). Да мало ли ещё вариантов. Не вижу особой потребности именно в линеаризации параллельного кода.
Так он не параллельный, а именно последовательный! Просто в местах, где стоит await может быть перескок в другой поток. Параллельным он может быть, разве что, для вызывающего метода, если тот не делает await на нашем, когда его вызывает (но async у нашего метода как раз намекает, что такое может случится). Типичный пример:

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

Тут надо учесть, что Button_Click вернет управление сразу и нужно задизэйблить кнопку, чтоб повторный запрос нельзя было сделать — UI не блокируется же.

_>>>Оно конечно длиннее, но лично мне больше нравится по ряду причин.
A>>Кто и как вызывает OnData? Что за ряд причин?
_>Главный цикл обработки сообщений UI потока. Т.е. это универсальный код, реализованный даже не под приложение, а вообще на уровне фреймворка.
Понятно, что цикл обработки сообщений UI потока. Интересуют детали.

_>А причины, как я уже сказал, исключительно субъективные и эстетические — мне не нравится, что на самом деле нелинейный код (в реальности там возникает "разрыв", в котором может происходить что угодно) визуально старается притвориться линейным. На мой вкус подобное затрудняет полноценное понимание кода.
И без разрыва может произойти что угодно, если у нас больше одного потока. И таки код не притворяется линейным, а таким и является, до тех пор пока мы параллельность явно делать не начнем (массивы тасков с WhenAny и т.п.).

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

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

A>>Блин, ты пойми, я не только такты считаю, я хочу, чтоб все ядра использовались и IO асинхронный был, но, при этом, код в спагетти не размотало.
_>Ну так и какие проблемы с многоядерностью у вышеуказанных инструментов? )
A>>Вот, например, сделаешь ты зеленые потоки в одном системном потоке — остальные ядра будут проставивать, даже когда работа есть, запросы новые идут.
_>Так почему я в одном то сделаю, а не на пуле? )
Если на пуле, то +1. Заблуждался на счет этого, Евгений меня переубедил.

A>>

Asynchronous completion handlers will only be called from threads that are currently calling io_service::run()

A>>Подозреваю, что тут лишний перескок из IOCP thread, не?
_>Вот тут http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/overview/core/async.html есть картинка, которая очень хорошо всё поясняет. )

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

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

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

A>>Что-нибудь, что позволяет выпрямить такой код:
A>>...
A>>А в идеале, чтоб, если захочется, еще можно было, например, завернуть все в try/catch:
A>>...

_>Если цель именно "выпрямлять", то по идее ничего кроме какой-то разновидности сопрограмм и не поможет. Моя же мысль была в том, что кроме "лапшевидного" и "выпрямленного" кода, могут быть и другие удобные варианты. Кроме уже упомянутых акторов можно вспомнить ещё и организацию обработки сообщений в классических ООП фреймворках (когда весь управляющий код скрыт где-то внутри, а пользователь библиотеки просто переопределяет пару нужных функций у наследуемого класса, которые будут сами вызваны фреймворком в нужный момент).
Да, но если в этих переопределенных функциях делать вызовы async IO...

_>Или например если взять машину состояний с нетривиальной реализацией (типа такого http://www.boost.org/doc/libs/1_56_0/libs/msm/doc/HTML/ch03s04.html#d0e1462 например). Да мало ли ещё вариантов. Не вижу особой потребности именно в линеаризации параллельного кода.
Так он не параллельный, а именно последовательный! Просто в местах, где стоит await может быть перескок в другой поток. Параллельным он может быть, разве что, для вызывающего метода, если тот не делает await на нашем, когда его вызывает (но async у нашего метода как раз намекает, что такое может случится). Типичный пример:

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

Тут надо учесть, что Button_Click вернет управление сразу и нужно задизэйблить кнопку, чтоб повторный запрос нельзя было сделать — UI не блокируется же.

_>>>Оно конечно длиннее, но лично мне больше нравится по ряду причин.
A>>Кто и как вызывает OnData? Что за ряд причин?
_>Главный цикл обработки сообщений UI потока. Т.е. это универсальный код, реализованный даже не под приложение, а вообще на уровне фреймворка.
Понятно, что цикл обработки сообщений UI потока. Интересуют детали.

_>А причины, как я уже сказал, исключительно субъективные и эстетические — мне не нравится, что на самом деле нелинейный код (в реальности там возникает "разрыв", в котором может происходить что угодно) визуально старается притвориться линейным. На мой вкус подобное затрудняет полноценное понимание кода.
И без разрыва может произойти что угодно, если у нас больше одного потока. И таки код не притворяется линейным, а таким и является, до тех пор пока мы параллельность явно делать не начнем (массивы тасков с WhenAny и т.п.).

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

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

A>>Блин, ты пойми, я не только такты считаю, я хочу, чтоб все ядра использовались и IO асинхронный был, но, при этом, код в спагетти не размотало.
_>Ну так и какие проблемы с многоядерностью у вышеуказанных инструментов? )
A>>Вот, например, сделаешь ты зеленые потоки в одном системном потоке — остальные ядра будут проставивать, даже когда работа есть, запросы новые идут.
_>Так почему я в одном то сделаю, а не на пуле? )
Если на пуле, то +1. Заблуждался на счет этого, Евгений меня переубедил.

A>>

Asynchronous completion handlers will only be called from threads that are currently calling io_service::run()

A>>Подозреваю, что тут лишний перескок из IOCP thread, не?
_>Вот тут http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/overview/core/async.html есть картинка, которая очень хорошо всё поясняет. )

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