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

I>>То есть, в кратце, короутин как минимум недостаточно для асинхронщины, нужен диспетчер прибитый гвоздями к эвентлупу.

EP>Хватит уже передёргивать, у нас уже была асинхронная функция:
EP>

EP>async_something([]
EP>{
EP>    MessageBox(0, TEXT("on min"), TEXT(""), MB_OK);
EP>});
EP>

и весь код ничего не знал про корутины. Они добавляются сюда локальной трансформацией кода

Эта короутина явно запускает эвентлуп.

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

A>Чуть более жизненный пример (раз уж просил):
A>

A>lock(sync)
A>{
A>  if(list != null)
A>    return list;

A>  list = new List();

A>  using(var stream = createStream())
A>  {
A>    string s;
A>    while ((s=stream.ReadLine())!=null) 
A>      list.Add(s);
A>  }
A>}

Вот и наскребли за сутки два примера

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

I>>>То есть, в кратце, короутин как минимум недостаточно для асинхронщины, нужен диспетчер прибитый гвоздями к эвентлупу.
EP>>Хватит уже передёргивать, у нас уже была асинхронная функция:
EP>>

EP>>async_something([]
EP>>{
EP>>    MessageBox(0, TEXT("on min"), TEXT(""), MB_OK);
EP>>});
EP>>

и весь код ничего не знал про корутины. Они добавляются сюда локальной трансформацией кода
I>Эта короутина явно запускает эвентлуп.

Ты про MessageBox что-ли, который был и без корутины?

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

G>Нет, там пул потоков оптимизированный под работу сервера. Создание дополнительных потоков на каждый чих ухудшает работу.

Ну вот видишь, а говорил можно без потоков... )))

G>С учетом реализации boost coroutine мой код порядка на два короче

Ну ты всё же уникальный, такое иногда придумаешь, чтобы только не признать чужую правоту, что просто шедевр. А может тогда за одно учтём ещё и размер реализации виндовыx fiber?

G>Нет макросов и дополнительных функций для маршалинга в UI.

Да, да, в C# нет макросов и поэтому у тебя код получился не только длиннее, но и заметно страшнее, с ручным протаскиванием yield, в котором легко ошибиться.

И кстати в варианте с асинхронным io у меня тоже нет никаких дополнительных функций.

G>Вот тебе решение той же задачи с async\await:

Это не решение той же задачи, т.к. ты тут модифицировал функцию ComplexFunc. Т.е. ты ещё раз доказал, что на async\await решить эту задачку не можешь. А вот на виндовых fiber'ax можешь. Всё логично.

Т.е. ты сам сейчас подтвердил мой основной тезис, что реализация async\await в C# слабее, т.к. заставляет нас переписывать существующий синхронный библиотечный код, в то время как его можно было бы спокойно использовать в асинхронном коде. И даже на .net'e.

G>А ты пытаешься доказать что на C# нельзя написать как на C++. Так оно и не нужно, есть более эффективные способы. Более того, на C++ гораздо хуже работает твой вариант, чем код выше.

Ооо, ну да, началась классическая песня "а оно нам и не нужно". Сразу почему-то вспоминаются фанаты продукции Apple...

G>Оно там есть. Как у тебя продолжения маршалятся в UI поток? Ты же из IOCP треда не дергаешь корутину?

Зачем, если это уже делает библиотека асинхронного io? ) Это было нужно именно в варианте с потоками и блокирующим io. Я потому и сказал, что он интереснее, т.к. там всё чуть сложнее. А с асинхронным io всё вообще просто.

G>Ты о чем? IOCP и есть очередь сообщений, ты про какую очередь?

Нет, очередь сообщений, это всего лишь один из вариантов работы с асинхронным io. Есть и другие, поинтереснее. В том числе и в винде. А например в линухе асинхронный io вообще только через сигналы — никаких очередей.

G>Ты реально гонишь...
G>В C++ все сильно завязано на стек, поэтому там нельзя автоматом переписывать хвост метода в продолжение, как это делает компилятор C#. Когда изобретут capture-by-move для лямбд, тогда это станет возможно, покачто нет.
G>А компилятор C еще более примитивный, он слишком низкоуровневый, чтобы таким заниматься.

Ты не понял смысл моей фразы. Речь о том, что когда у нас критична производительность, то нам уже не до красивостей в коде — главное результат. Поэтому надо брать максимально быстрое решение, как бы оно там не выглядело.

G>Кстати nginx не быстрее IIS

Ага, ага. И как раз поэтому популярность apache и iis падает при переходе к более нагруженным серверам, а у nginx наоборот http://w3techs.com/technologies/cross/web_server/ranking.

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

I>А кто гарантирует, что новых вызовов не будет ? Представь, в однопоточном коде сто штук таких вот вызово. Когда синхронно, все шоколадно — отработали последовательно, каждая следующая модифицирует результат предыдущей.
I>Когда появляется асинхронщина, каждая следующая перезатирает результат предыдущей.

Как это кто гарантирует? Мы конечно же! Ведь это всё происходит уже в нашем асинхронном коде приложения, а не в неизвестном библиотечном.

Вот смотри. Допустим есть такая (как у тебя) библиотечная функция:

void f(R read, W write)
{
    auto v=read();
    write(next(v));
}

и синхронный код:

for(;;) f(read, write);

Мы конечно же можем написать такой асинхронный код:

for(;;) async_code(
    f(async_read, write);
)

и получим как раз описанную тобой проблему. Но это будет следствием исключительно кривизны нашего асинхронного кода, а не особенностью реализации библиотечной функции (про которую мы типа ничего не знаем). Стоит нам написать так:

async_code(
    for(;;) f(async_read, write);
)

и проблема исчезнет — код станет полностью корректным.

Т.е. если мы пишем корректный асинхронный код, то использование синхронных библиотечных функций нам ничуть не мешает.

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

_>Т.е. если мы пишем корректный асинхронный код, то использование синхронных библиотечных функций нам ничуть не мешает.

То есть, с++ с короутинами ничем не поможет, т.к. корректных синхронный код и полученый из него асинхронный это две большие разницы

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

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

G>>Нет, там пул потоков оптимизированный под работу сервера. Создание дополнительных потоков на каждый чих ухудшает работу.
_>Ну вот видишь, а говорил можно без потоков... )))
Я говорил что не нужно их создавать, это сильно разные утверждения.

G>>С учетом реализации boost coroutine мой код порядка на два короче
_>Ну ты всё же уникальный, такое иногда придумаешь, чтобы только не признать чужую правоту, что просто шедевр. А может тогда за одно учтём ещё и размер реализации виндовыx fiber?
Тогда давай сразу всего виндовса, чего уж там

G>>Нет макросов и дополнительных функций для маршалинга в UI.
_>Да, да, в C# нет макросов и поэтому у тебя код получился не только длиннее, но и заметно страшнее, с ручным протаскиванием yield, в котором легко ошибиться.
Чувак, да успокойся, такой бред в здравом уме никто писать не будет. И ошибаться не будет соответственно.

_>И кстати в варианте с асинхронным io у меня тоже нет никаких дополнительных функций.

G>>Вот тебе решение той же задачи с async\await:

_>Это не решение той же задачи, т.к. ты тут модифицировал функцию ComplexFunc. Т.е. ты ещё раз доказал, что на async\await решить эту задачку не можешь. А вот на виндовых fiber'ax можешь. Всё логично.
Чувак, таже же задача — это одинаковый output при одинаковых input. Ограничения ты всегда сам себе придумываешь.
В реальной жизни неподходящую библиотеку просто перепишут.
В отличие от C++ в .NET встроенная библиотека на несколько порядков мощнее, чем C++ даже с бустом. Поэтому нет необходимости привлекать шандарахнутые dll, которые не поддерживают асинхронность.

Описанная тобой проблема только в С++ и существует. В .NET её нет и, соответственно, решать её никто не собирается.

_>Т.е. ты сам сейчас подтвердил мой основной тезис, что реализация async\await в C# слабее, т.к. заставляет нас переписывать существующий синхронный библиотечный код, в то время как его можно было бы спокойно использовать в асинхронном коде. И даже на .net'e.
Ты думаешь от повторения ты правее станешь? Или ты таки покажешь как масштабировать корутины? Чтобы не надо было эвентлуп крутить, ибо в серверном варианте это жопа.

G>>А ты пытаешься доказать что на C# нельзя написать как на C++. Так оно и не нужно, есть более эффективные способы. Более того, на C++ гораздо хуже работает твой вариант, чем код выше.
_>Ооо, ну да, началась классическая песня "а оно нам и не нужно". Сразу почему-то вспоминаются фанаты продукции Apple...
Чувак, это ты начал такие песи, рассказывая что linq и yield не нужен
А по поводу твоей проблемы — таки не нужно, мне за 5 лет один раз понадобилось работать с библиотекой, которая не поддерживала асинхронность. И я её переписал на таски, банально открыв в Reflector и выдрав нужный мне код.


G>>Оно там есть. Как у тебя продолжения маршалятся в UI поток? Ты же из IOCP треда не дергаешь корутину?

_>Зачем, если это уже делает библиотека асинхронного io? ) Это было нужно именно в варианте с потоками и блокирующим io. Я потому и сказал, что он интереснее, т.к. там всё чуть сложнее. А с асинхронным io всё вообще просто.

Что делает? В UI маршалит?
Корутины могут исполняться только в "owning thread" из документации, это значит что тебе надо асинхронные вызовы маршалить в "owning thread". Обычно это делается через очереди и message pump, как в твоем примере. Даже когда ты юзаешь asio у тебя есть очередь дождавшихся завершения IO корутин.
То есть ты можешь увеличить плотность потоков, на одном системном запускать несколько корутин, но эффективно использовать ресурсы компьютера (читай использовать work-stealing) не получится. Плюс ты имеешь накладные расходы на маршалинг и message pump.

В .NET из-за отсутствия привязки к "owning thread" можно использовать пулы потоков, не делать message pump, параллелить работу.

G>>Ты о чем? IOCP и есть очередь сообщений, ты про какую очередь?

_>Нет, очередь сообщений, это всего лишь один из вариантов работы с асинхронным io. Есть и другие, поинтереснее. В том числе и в винде. А например в линухе асинхронный io вообще только через сигналы — никаких очередей.
И что?

G>>Ты реально гонишь...
G>>В C++ все сильно завязано на стек, поэтому там нельзя автоматом переписывать хвост метода в продолжение, как это делает компилятор C#. Когда изобретут capture-by-move для лямбд, тогда это станет возможно, покачто нет.
G>>А компилятор C еще более примитивный, он слишком низкоуровневый, чтобы таким заниматься.

_>Ты не понял смысл моей фразы. Речь о том, что когда у нас критична производительность, то нам уже не до красивостей в коде — главное результат. Поэтому надо брать максимально быстрое решение, как бы оно там не выглядело.
Нет. Ты начал говорить о каких-то накладных расходах, вот я и спрашиваю о каких ты говоришь. Ибо async мало что вносит в код, основная работа делается асинхронными методами, которые еще со времен .NET 1.0 существуют.

G>>Кстати nginx не быстрее IIS
_>Ага, ага. И как раз поэтому популярность apache и iis падает при переходе к более нагруженным серверам, а у nginx наоборот http://w3techs.com/technologies/cross/web_server/ranking.
Тут ты вообще не в теме. Вопрос не в скорости, а в цене. ngix почти всегда используется как reverse proxy, тупо дешевле, не надо лицензии на венду покупать.
Особенно важно когда надо апач экранировать с php, ибо он умирает от 40 одновременных запросов на сервак.

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

I>То есть, с++ с короутинами ничем не поможет, т.к. корректных синхронный код и полученый из него асинхронный это две большие разницы

Так это само собой. Фокус в том, что мы при этом можем спокойно использовать в асинхронном стеке вызова синхронные библиотечные функции. А в C# не можем — их надо переписывать заново.

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

I>>То есть, с++ с короутинами ничем не поможет, т.к. корректных синхронный код и полученый из него асинхронный это две большие разницы

_>Так это само собой. Фокус в том, что мы при этом можем спокойно использовать в асинхронном стеке вызова синхронные библиотечные функции.

И получишь показное мною нарушение инварианта.

>А в C# не можем — их надо переписывать заново.

Правильно !

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

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

I>>А кто гарантирует, что новых вызовов не будет ? Представь, в однопоточном коде сто штук таких вот вызово. Когда синхронно, все шоколадно — отработали последовательно, каждая следующая модифицирует результат предыдущей.
I>>Когда появляется асинхронщина, каждая следующая перезатирает результат предыдущей.

_>Как это кто гарантирует? Мы конечно же! Ведь это всё происходит уже в нашем асинхронном коде приложения, а не в неизвестном библиотечном.

Но тогда ты должен знать как работает этот библиотечный код. Вдруг создает тред и дергает твою функцию, все, твоя хитрая система рассыпается.

_>Т.е. если мы пишем корректный асинхронный код, то использование синхронных библиотечных функций нам ничуть не мешает.
Это в теории, а на практике ограничений будет выше крыши.
Судя по гуглу такими извращениями только пара человек на rsdn и занимается, а все остальные предпочитают писать нормальный код.


Да и вообще непонятно зачем нужна такая асинхронность, которая:
1) тормозит
2) не машстабируется

Это какой-то мертворожденный подход.

_>>А мне кажется, то что менеджмент яху, в отличии от раннего гугла, не умел строить бизнес силами маргиналов, как раз и есть причина их быстрого слива по всем направлениям

J>О чем я и говорил в том сообщении, на которое ты отвечаешь

Таки из твоего сообщения получается что язык годен для бизнеса тогда и только тогда когда всё готово, есть программисты, книжки, библиотеки и т.п., т.е. когда это уже мэйнстрим. Но для получения конкурентного преимущества необходимо использовать инженерные решения на шаг впереди мэйнстрима. А это как раз ниша маргинальных языков. Гугл взлетал одновременно с падением яхи, и вполне себе спокойно использовал маргинальный и незрелый тогда питон (значительная доля популярности которого выросла на хайпе вокруг гугла). У яху такого менеджмента просто не было, вот они не смогли удержать то что купили.

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

G>В отличие от C++ в .NET встроенная библиотека на несколько порядков мощнее, чем C++ даже с бустом. Поэтому нет необходимости привлекать шандарахнутые dll, которые не поддерживают асинхронность.

Забавное утверждение. Не подскажешь тогда случаем, как во встроенной библиотеке .Net называется раздел аналогичный например Boost.Spirit? )

G>Чувак, это ты начал такие песи, рассказывая что linq и yield не нужен

Да, я считаю что не нужны, но при этом я привёл их работающие реализации. Почувствуй разницу ситуаций:

моя: не нужны (потому что есть способы сделать тоже самое лучше), но без проблем можно реализовать.
твоя: не нужны (потому что нельзя реализовать) — мне не лень переписывать заново чужие библиотеки.

G>А по поводу твоей проблемы — таки не нужно, мне за 5 лет один раз понадобилось работать с библиотекой, которая не поддерживала асинхронность. И я её переписал на таски, банально открыв в Reflector и выдрав нужный мне код.

Ага, ага.

G>Корутины могут исполняться только в "owning thread" из документации, это значит что тебе надо асинхронные вызовы маршалить в "owning thread". Обычно это делается через очереди и message pump, как в твоем примере. Даже когда ты юзаешь asio у тебя есть очередь дождавшихся завершения IO корутин.

Callback во всех известных мне C++ библиотеках асинхронного io вызывается именно в том потоке, который я укажу, а не в каком-то там неизвестном.

G>Нет. Ты начал говорить о каких-то накладных расходах, вот я и спрашиваю о каких ты говоришь. Ибо async мало что вносит в код, основная работа делается асинхронными методами, которые еще со времен .NET 1.0 существуют.

Ну да, о том и речь. Как бы даже если накладные расходы от async небольшие (хотя смотря с чем сравнивать), то всё равно они лишние, т.к. никакой функциональности при этом не приносят.

G>Тут ты вообще не в теме. Вопрос не в скорости, а в цене. ngix почти всегда используется как reverse proxy, тупо дешевле, не надо лицензии на венду покупать.

Да, да, у топ 1000 по посещению (типа яндекс, вконтаке, фейсбука) не хватает денег на лицензию винды. Исключительно поэтому они используют бесплатный Linux с nginx.

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

I>И получишь показное мною нарушение инварианта.

Я же показал тебе, что не получу, если напиши корректный асинхронный код (не меняя синхронную библиотечную функцию). Или же ты хочешь сказать, что если я напишу на C# так:

async void f(read, write)//вот она твоя переписанная функция по всем правилам
{
    var v=await read();
    write(next(v));
}
f(async_read, write);
f(async_read, write);

то получится корректный код? ) А это полный аналог того, что ты предлагаешь мне как приводящий к ошибкам код на C++...

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

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

G>>В отличие от C++ в .NET встроенная библиотека на несколько порядков мощнее, чем C++ даже с бустом. Поэтому нет необходимости привлекать шандарахнутые dll, которые не поддерживают асинхронность.

_>Забавное утверждение. Не подскажешь тогда случаем, как во встроенной библиотеке .Net называется раздел аналогичный например Boost.Spirit? )

Парсеры XML и JSON уже есть. Для более сложных вещей обычно используются нормальные генераторы парсеров.
Spirit это не от хорошей жизни, а от бедности базовой библиотеки.


G>>Чувак, это ты начал такие песи, рассказывая что linq и yield не нужен
_>Да, я считаю что не нужны, но при этом я привёл их работающие реализации. Почувствуй разницу ситуаций:
_>моя: не нужны (потому что есть способы сделать тоже самое лучше), но без проблем можно реализовать.
_>твоя: не нужны (потому что нельзя реализовать) — мне не лень переписывать заново чужие библиотеки.
Ты ничего "лучше" не показал То что ты показал — тормозит, не масштабируется, не решает реальные проблемы, которые существуют в .NET, решает проблемы, которых в .NET никогда не было.
В остальном ты прав

G>>Корутины могут исполняться только в "owning thread" из документации, это значит что тебе надо асинхронные вызовы маршалить в "owning thread". Обычно это делается через очереди и message pump, как в твоем примере. Даже когда ты юзаешь asio у тебя есть очередь дождавшихся завершения IO корутин.
_>Callback во всех известных мне C++ библиотеках асинхронного io вызывается именно в том потоке, который я укажу, а не в каком-то там неизвестном.
Да, и это как раз проблема. С таким ограничением work-stealing хрен сделаешь.

G>>Нет. Ты начал говорить о каких-то накладных расходах, вот я и спрашиваю о каких ты говоришь. Ибо async мало что вносит в код, основная работа делается асинхронными методами, которые еще со времен .NET 1.0 существуют.

_>Ну да, о том и речь. Как бы даже если накладные расходы от async небольшие (хотя смотря с чем сравнивать), то всё равно они лишние, т.к. никакой функциональности при этом не приносят.
Еще как приносят, потому async методы переписываются в продолжения. Руками такое сделать в 100 раз сложнее и больше вероятность внести ошибку.
Если бы async ничего не давал, то его бы не использовали. А его используют массово.


G>>Тут ты вообще не в теме. Вопрос не в скорости, а в цене. ngix почти всегда используется как reverse proxy, тупо дешевле, не надо лицензии на венду покупать.

_>Да, да, у топ 1000 по посещению (типа яндекс, вконтаке, фейсбука) не хватает денег на лицензию винды. Исключительно поэтому они используют бесплатный Linux с nginx.
Ты удивишься, но это действительно так. Ты очень далек от реальной экономики.

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

_>>>А мне кажется, то что менеджмент яху, в отличии от раннего гугла, не умел строить бизнес силами маргиналов, как раз и есть причина их быстрого слива по всем направлениям

J>>О чем я и говорил в том сообщении, на которое ты отвечаешь

_>Таки из твоего сообщения получается что язык годен для бизнеса тогда и только тогда когда всё готово, есть программисты, книжки, библиотеки и т.п., т.е. когда это уже мэйнстрим. Но для получения конкурентного преимущества необходимо использовать инженерные решения на шаг впереди мэйнстрима. А это как раз ниша маргинальных языков. Гугл взлетал одновременно с падением яхи, и вполне себе спокойно использовал маргинальный и незрелый тогда питон (значительная доля популярности которого выросла на хайпе вокруг гугла). У яху такого менеджмента просто не было, вот они не смогли удержать то что купили.

Именно так, я и говорил, что маргинальные языки — удел стартапов, а в больших компаниях от них больше вреда, чем пользы.

ЗЫ ну и я не думаю, что Питон — это технологический фундамент гугла

You will always get what you always got
  If you always do  what you always did

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

_>>Забавное утверждение. Не подскажешь тогда случаем, как во встроенной библиотеке .Net называется раздел аналогичный например Boost.Spirit? )
G>Парсеры XML и JSON уже есть. Для более сложных вещей обычно используются нормальные генераторы парсеров.
G>Spirit это не от хорошей жизни, а от бедности базовой библиотеки.

Хыхы, ты всё же великолепен. Думаю достоин звания "лучший мастер отмазок rsdn'a".

G>>>Чувак, это ты начал такие песи, рассказывая что linq и yield не нужен
_>>Да, я считаю что не нужны, но при этом я привёл их работающие реализации. Почувствуй разницу ситуаций:
_>>моя: не нужны (потому что есть способы сделать тоже самое лучше), но без проблем можно реализовать.
_>>твоя: не нужны (потому что нельзя реализовать) — мне не лень переписывать заново чужие библиотеки.
G>Ты ничего "лучше" не показал То что ты показал — тормозит, не масштабируется, не решает реальные проблемы, которые существуют в .NET, решает проблемы, которых в .NET никогда не было.
G>В остальном ты прав

Вообще то это был речь о другом. О linq (boost.range), yield (итераторы) и т.п. Что же касается обсуждаемого тут решения await/async в C++, то на мой взгляд это опять же из категории "можно без проблем реализовать на C++, хотя и не особо нужно". То, что оно при этом получилось ещё и лучше оригинала — это так, просто забавный нюанс.

G>Еще как приносят, потому async методы переписываются в продолжения. Руками такое сделать в 100 раз сложнее и больше вероятность внести ошибку.

Ещё раз, это польза для программиста, а не для быстродействия продукта. Точнее оно его даже уменьшает.

G>Если бы async ничего не давал, то его бы не использовали. А его используют массово.

Да, потому что высоконагруженные серверы массово не пишут. )))

_>>Да, да, у топ 1000 по посещению (типа яндекс, вконтаке, фейсбука) не хватает денег на лицензию винды. Исключительно поэтому они используют бесплатный Linux с nginx.
G>Ты удивишься, но это действительно так. Ты очень далек от реальной экономики.

О сколько нам открытий чудных готовит обычный программистский форум. )

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

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

_>>>Забавное утверждение. Не подскажешь тогда случаем, как во встроенной библиотеке .Net называется раздел аналогичный например Boost.Spirit? )
G>>Парсеры XML и JSON уже есть. Для более сложных вещей обычно используются нормальные генераторы парсеров.
G>>Spirit это не от хорошей жизни, а от бедности базовой библиотеки.

_>Хыхы, ты всё же великолепен. Думаю достоин звания "лучший мастер отмазок rsdn'a".

Конечно, когда аргументы кончаются начинают искать причины в оппоненте.
Ну давай покажи какие realworld проблемы решает spirit. На проверку окажется что 90% уже решены в современных платформах, а еще 10% закрываются специальными средствами.
Это кстати не только spirit касается, но и других "универсальных всемогутеров".

G>>>>Чувак, это ты начал такие песи, рассказывая что linq и yield не нужен
_>>>Да, я считаю что не нужны, но при этом я привёл их работающие реализации. Почувствуй разницу ситуаций:
_>>>моя: не нужны (потому что есть способы сделать тоже самое лучше), но без проблем можно реализовать.
_>>>твоя: не нужны (потому что нельзя реализовать) — мне не лень переписывать заново чужие библиотеки.
G>>Ты ничего "лучше" не показал То что ты показал — тормозит, не масштабируется, не решает реальные проблемы, которые существуют в .NET, решает проблемы, которых в .NET никогда не было.
G>>В остальном ты прав

_>Вообще то это был речь о другом. О linq (boost.range), yield (итераторы) и т.п. Что же касается обсуждаемого тут решения await/async в C++, то на мой взгляд это опять же из категории "можно без проблем реализовать на C++, хотя и не особо нужно". То, что оно при этом получилось ещё и лучше оригинала — это так, просто забавный нюанс.
Ты опять повторяешь заблуждение что решение на C++ лучше. Оно не лучше потому что:
1) тормозит
2) не масштабируется

Живое решение может иметь максимум один недостаток, а вот у "решения" на C++ оба.

В отличие от "решения" на C++, конструкции async\await и TPL не тормозят и масштабируются. Более того, придуманный 5 лет назад AsyncEnumerator на итераторах, работающий почти также, как твой пример на C++, масштабировался.

G>>Еще как приносят, потому async методы переписываются в продолжения. Руками такое сделать в 100 раз сложнее и больше вероятность внести ошибку.
_>Ещё раз, это польза для программиста, а не для быстродействия продукта. Точнее оно его даже уменьшает.
С чего ты взял? perceived performance от async IO растет, а распараллеливание IO без блокировки потоков делает софт быстрее\улучшает масштабируемость.
Но в твоем случае надо еще руками реализовывать параллельность IO.

G>>Если бы async ничего не давал, то его бы не использовали. А его используют массово.
_>Да, потому что высоконагруженные серверы массово не пишут. )))
Очень много пишут. Уж побольше чем корутины

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

Теперь Александреску побрил ежика

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

_>Я же показал тебе, что не получу, если напиши корректный асинхронный код (не меняя синхронную библиотечную функцию). Или же ты хочешь сказать, что если я напишу на C# так:
_>

_>async void f(read, write)//вот она твоя переписанная функция по всем правилам
_>{
_>    var v=await read();
_>    write(next(v));
_>}
_>f(async_read, write);
_>f(async_read, write);
_>

_>то получится корректный код? ) А это полный аналог того, что ты предлагаешь мне как приводящий к ошибкам код на C++...

Если по f ты подразумеваешь асинхронный мутекс, то это будет правильный код.

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

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

I>>То есть, в кратце, короутин как минимум недостаточно для асинхронщины, нужен диспетчер прибитый гвоздями к эвентлупу.

EP>Хватит уже передёргивать, у нас уже была асинхронная функция:
EP>

EP>async_something([]
EP>{
EP>    MessageBox(0, TEXT("on min"), TEXT(""), MB_OK);
EP>});
EP>

и весь код ничего не знал про корутины. Они добавляются сюда локальной трансформацией кода

Объяснил бы мне кто-нибудь вот что:

1. Асинхронные операции могут выполняться (и\или завершаться) в другом потоке (потоке IOCP, потоке тред пула или явно создаваемом потоке при старте асинхронной операции).
   
2. При кооперативной многозадачности со stackfull coroutines работа выполняется в одном системном потоке, т.е. этот поток должен существовать постоянно и как-то уметь "ждать" окончания асинхронных операций из первого пункта.

Вопрос: как реализовано это "ожидание"? Гоняем холостой цикл с проверками "а не завершился ли кто"? Ждем на каком-нибудь системном объекте синхронизации (системном событии, например)? Как-то еще?