EP>В C#'пе нужный message pump выбирается глобальным synchronization context'ом, что и я и artelk пытались тебе растолковать

EP>Ничто не мешает иметь такой же глобальный synchronization context

EP>2. Это может быть на нижних уровнях, без изменения интерфейса выше. Внутри TcpStream, показанного выше, о ужас, тоже есть yield

EP>Сделать тоже самое один раз, и спрятать в либу

EP>балабольство — ты так и не показал аналог кода на C##

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

— так что сравнивать не с чем

void foo(Stream stream)
{
    string msg;
    do
    {
        msg = getline(stream);
        Trace.WriteLine(msg); 
    } while(msg != "exit");
}

Вариант 1: генераторы
IEnumerable<string> StrinsForStream()
{
  yield return "1";
}

foo(new StreamFromEnumerable (StrinsForStream()));

class StreamFromEnumerable : Stream
{
...
   if(strings.MoveNext())
     return strings.Current;
   else
     return "exit";
...

}

Вариант 3: эвенты
foo(new StreamFromEvents (()=>GetNextString()));

class StreamFromEvents : Stream
{
...
       return strings.RequestNextString() ?? "exit";
...

}

Вариант 3: олдскульноее ООП, которое есть даже в Джаве, Джаваскрипте и где угодно

class StringsRequester : IStringsRequester
{
  string IStringsRequester.Next()
  {
    ... // return все что хочешь и как хочешь
  } 
}

foo(new StreamFrom(new StringsRequester());

class StreamFrom : Stream
{
...
       return stringRequester.Next() ?? "exit";
...

}

I>>>>>Ну это просто вранье. alex_public показал, как event-loop "не меняется" — путем встраивания RunAll в event loop или прикручивая таймер

EP>>>>Так я же выше показывал пример с полностью локальной трансформацией, без модификации event-loop

EP>>Так и тут continuations прячутся под капот, пользовательский код остаётся линейным

async_something([=]{ on_completion(); });

s_.async_read_some(
        boost::asio::buffer( buffer_ + pb_size, bf_size - pb_size),
        boost::bind( & coro_t::operator(), & coro_, _1, _2) );
ca_();

EP>>В C#'пе нужный message pump выбирается глобальным synchronization context'ом, что и я и artelk пытались тебе растолковать

Task(() -> calc()).then(on_global_sync_context, () -> on_completion() );

async_something([=]{ on_completion(); });
// ...
void async_something(CompletionHandler ch)
{
    Task(calc).then(on_global_sync_context, ch );
}

template<typename F>
void async_something(F f)
{
    on_minization = f;
}

EP>>Ничто не мешает иметь такой же глобальный synchronization context

Task(() -> calc()).then(on_global_sync_context, () -> on_completion() );

I>void foo(Stream stream)
I>{
I>    string msg;
I>    do
I>    {
I>        msg = getline(stream);
I>        Trace.WriteLine(msg); 
I>    } while(msg != "exit");
I>}
I>

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

void async_something(Handler h)
{
    async_download(address).then(sync_context, h);
}
// ...
async_something([=]{ on_completion(); });

async_something([=]{ on_completion(); });

EP>Boost не нужно никак модифицировать

EP>Task(() -> calc()).then(on_global_sync_context, () -> on_completion() );
EP>

EP>>>Ничто не мешает иметь такой же глобальный synchronization context

EP>Task(() -> calc()).then(on_global_sync_context, () -> on_completion() );
EP>

EP>механически трансформируется на корутины — в нём уже есть этот самый synchronization context

I>>void foo(Stream stream)
I>>{
I>>    string msg;
I>>    do
I>>    {
I>>        msg = getline(stream);
I>>        Trace.WriteLine(msg); 
I>>    } while(msg != "exit");
I>>}
I>>

while(::GetMessage(&msg))
{
  ::DispatchMessage(msg);
}

И один из хандлеров внезапно вызывает getline вот так

getline(stream, &result) // здесь нить ожидает результата и вместе с ней висит message pump выше -> UI Thread блокирован для вызовов извне, соответсвенно нужно что бы другая нить вызвала этот самый message pump

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

await async_download(address);
on_completion();

EP>>>>Ничто не мешает иметь такой же глобальный synchronization context

EP>>Task(() -> calc()).then(on_global_sync_context, () -> on_completion() );
EP>>

EP>>механически трансформируется на корутины — в нём уже есть этот самый synchronization context

I>>>void foo(Stream stream)
I>>>{
I>>>    string msg;
I>>>    do
I>>>    {
I>>>        msg = getline(stream);
I>>>        Trace.WriteLine(msg); 
I>>>    } while(msg != "exit");
I>>>}
I>>>

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

//Schedules the state machine to proceed
//to the next action when the specified awaiter completes.
//Also: sending this state machine here will trigger it's boxing into heap.
this.<>t__builder.AwaitUnsafeOnCompleted<TaskAwaiter<string>, 
  AsyncMethods.<DownloadHtmlAsyncTask>d__0>(ref taskAwaiter, ref this);

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

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

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

EP>>getline дёрнет TcpStream, который вызовет yield, после которого управление вернётся в message pump

EP>>Контексты и message-pump-ы есть и до распрямления, очевидно же

Asynchronous I/O, in computer science, is a form of input/output processing that permits other processing to continue before the transmission has finished.

await async_download(address);
on_completion();