I>function getSin(param, end)
I>{
I>  end(Math.sin(param));
I>}

I>getSin(45, function(result){ ля ля ля})

I>вот этот вызов выглядит как асинхронный, при этом в данном примере нет ничего асинхронного, обычный event driven подоход, а вы с EP почему то называете такой хлам асинхронщиной
I>

Read(buf, coro);//передаём вместо обычного callback'a наш специальный на базе сопроцедуры
yield();//вызодим из функции
ProcessBuf(buf);//выполняется как callback функции read, но в контексте текущей функции

EP>>ловко ты async_something превратил просто в something, ага

EP>>так ведь и async_download

Автор: Ikemefula
Дата: 07.07.13

спокойно превращается в download

I>Ты так и не понял, что такое async await

async_download(address).then(sync_context, [=]{ on_completion(); } );

I>вот этот вызов выглядит как асинхронный, при этом в данном примере нет ничего асинхронного, обычный event driven подоход, а вы с EP ты почему то называете называешь такой хлам асинхронщиной

Вот тут:

for(auto &buffer : buffers)
        fibers.emplace_back(bind(coroutine_start, &buffer, _1));

Вызываются "handler"'ы (в твоих терминах).
В каждом "handler"'е код выполняется до каждого yield'а и сразу возвращается сюда — так же как и в C# с async/await код выполняется до первого await'а. Это в твоих понятиях являются асинхронными вызовами или нет?
Когда "event loop" ныряет в сопроцедуру — это аналог тому, когда await дожидается своего таска.
Все остальные yield'ы в "handler"'ах — аналогичны последующим await'ам и т.п.

EP>>И где связь между твоим getSin, который сразу вызывает продолжение с результатом, и getline который внутри yield'ится в main loop?

stream address: 0x7fc742afdc10| Hello
stream address: 0x7fc742aebc10| World
stream address: 0x7fc742ad9c10| Stackfull
stream address: 0x7fc742ac7c10| Coroutines
stream address: 0x7fc742ad9c10| Rulez!
stream address: 0x7fc742aebc10| Hasta la vista
stream address: 0x7fc742afdc10| Baby
stream address: 0x7fc742afdc10| exit
stream address: 0x7fc742aebc10| exit
stream address: 0x7fc742ad9c10| exit
stream address: 0x7fc742ac7c10| exit

string msg;
do
{
    getline(client_stream, msg);
    cout << "stream address: " << &client_stream << "|\t";
    cout << msg << endl;
} while(msg != "exit");

EP>>coroutine_start

Автор: Evgeny.Panasyuk
Дата: 26.06.13

вызванный из корутины, и имеющий внутри getline тоже неблокирующий

EP>>И внутри он yield'нулся обратно в message pump

EP>>Я уже показал пример асинхронной операции с win32 message pump. Делать ещё примеры нет никакого желания, по двум причинам: с твоей стороны не было запрошенных примеров (кроме неработающих огрызков), на каждый мой пример ты придумываешь нелепые отмазки

I>Вот и покажи эту асинхронщину на короутинах. Забудь про MesageBox, TcpStream и тд. Сделай что нибудь внятное, ну хоть Thread.Sleep() если ничего в голову не приходит.
Покажи версию без корутин на C++ — я её переделаю на корутины. А то ты опять будешь кричать что это не "асинхронщина".

EP>>Вызов getline, с точки зрения метода foo, очевидно блокирующий

На stackless coroutine такая инкапсуляция не получится — асинхронные кишки будут торчать в клиентском коде, ибо такие сопроцедуры (без асинхронных кишок в клиентском коде) сразу возвращают управление в клиентский код — а это значит что либо данные ещё не получены, либо никакой асинхронности, так как только один поток.