Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Как помогут легковесные потоки если IO блокирующий, как в твоем примере?
_>А причём тут легковесные потоки и мой пример? У меня там, как ты видел, обычное десктопное приложение (окошко с кнопкой), а не сервер с тысячами подключений. Зачем мне там такие потоки?
Наверное потому что async\await отлично работает как на клиенте, так и на сервере. А ты сделал менее эффективный пример, который и этом нифига не масштабируется.
G>>Неблокирование путем создания другого потока — хреновая идея. В твоем примере так. _>Ну покажи в чём хреновость. )
Если ты начнешь масштабировать свой подход, то он начнет дико тормозить. А если подход нельзя масштабировать, то нафига он такой нужен? Решить частную задачу по созданию асинхронности одной функции можно запустив её в отдельном потоке, дописав маршалинг вызовов в UI и получится меньше чем пляски с корутинами\шаблонами\макросами.
G>>А чем копирование файла отличается от считывания потока данных из сети и записи на диск?
_>Не важно что и куда, а важно сколько операций параллельно. Реализация через пару системных потоков будет максимально эффективной и для сети (собственно там вообще идеально, т.к. устройства точно разные). Однако если нам понадобится много таких параллельных скачиваний, то эффективность будет ухудшаться с их увеличением. Так что начиная с какого-то момента уже выгоднее использовать другую модель (легковесные потоки например).
А можно не выдумывать хрень и использовать IOCP, эффективнее на винде ниче пока не придумали.
Вот только код будет не такой, как у тебя.
_>>>Конечно не тоже самое. C# реализация заметно более слабая. ))) Или быть может ты уже готов показать решение той тривиальной тестовой задачки? G>>Легко.
_>Это была речь про эту http://www.rsdn.ru/forum/philosophy/5357968
Здравствуйте, gandjustas, Вы писали:
G>Читал, а толку то? Этот подход решает очень узкую задачу — асинхронное чтение буковок. Это можно и с меньшим количеством кода сделать. G>На обобщенный метод превращения синхронного кода в асинхронный не тянет.
std::getline тут стандартная, не модифицированная. Точно также можно протащить yield и через любую другую функцию
EP>>Что значит особый случай? Точно также можно завернуть tcp_stream. G>Надо очень хорошо знать как код работает внутри, чтобы делать такую асинхронность.
Есть любая асинхронная функция которая принимает continuation/.then — мы ей передаём в этот continuation код с yield-ом внутри, что механически превращает остаток нашей функции в продолжение.
G>А как комбинировать такие асинхронные вызовы не то что не очевидно, а вообще непонятно как.
Ты о чём?
EP>>При этом код использующий этот поток не поменяется, а в случае с C# await — нужно будет патчить весь call-stack G>А зачем это делать? Преобразование синхронного кода в асинхронный — механическая операция, легко автоматизируется при желании. Я даже для стримов на roslyn такое переписывание делал.
С такими же рассуждениями можно прийти к мысли что и yield, и await/async не нужны
Зачем переделывать весь код если можно просто передать ему объект другого типа?
Или как в том же gevent это:
monkey.patch_all()
всё — ничего переписывать не надо
EP>>Причём большую часть boilerplate'а необходимого для заворачивания в корутины, легко вынести в библиотеку G>Почему до сих пор никто не сделал? Видимо не так просто, ибо более чем востребовано в наше время.
(это при том что я сам практически не работаю ни с каким io).
G>>>Кроме того все это выполняется через глобальную переменную. Запустить два таких считывания уже не выйдет. EP>>Это минимальный пример показывающий как вызов std::getline может работать с асинхронным потоком. G>Проблема в том, что они показывает только вызов std::getline. Покажи как сделать тоже самое с вводом-выводом на IOCP. EP>>Если будет async_tcp_stream — то будет хоть 100k соединений G>Для начала тебе надо будет async io реализовать на IOCP.
Ты мне предлагаешь реализовать свои обвёртки поверх голого IOCP? Зачем?
G>>>Ты считаешь что такое "решение" способно тягаться с async\await в C#? EP>>await-like синтаксис легко реализуется поверх корутин
, только получается намного мощнее, так как не ограничен одним уровнем. G>Каким одним уровнем? ты о чем?
О том, что для того чтобы сделать yield с самого низа callstack'а на самый вверх, тебе придётся дублировать и модифицировать каждый уровень. Причём эти уровни могут находится в библиотеках к которым нет доступа.
G>>>А вот ты на C# await повторить пример с getline-like никак не сможешь. Разве не очевидно что мощнее G>А зачем его повторять? Я же говорю что просто дописываешь async\await где можно код становится асинхронным. Даже понимать не надо как код работает.
У тебя нет кода std::getline (или аналога) — куда ты там собрался дописывать await?
Да даже если взять что-то совершенно не связанное с вводом/выводом, например есть любая функция которая принимает другую функцию как параметр. Ты передаёшь лямбду внутри которой надо yield'нуть/await'нуть — где ты тут что будешь дописывать?
Здравствуйте, gandjustas, Вы писали:
G>>> Сейчас спектр систем, где заработает код на C#, примерно такой же, как у java и у обоих гораздо шире, чем у C++. EP>>C++ работает и на десктопах, и на планшетах, и на телефонах (разве что кроме первых версий windows phone), и на 8-битных контролерах, и даже <b><u>внутри javascript</u></b> G>А в браузере на клиенте?
Да, в браузере, на клиенте — открой ссылку выше.
Даже QT работает.
Здравствуйте, gandjustas, Вы писали:
G>В выделенном коде у тебя порождается новый поток. Это бредовая асинхронность...
А ты никакую другую и не сделаешь, если у тебя по условию задачи входной поток данных блокирующий. Ну и в любом случае, даже если предположим она бредовая, то повтори хоть такую. Ты же обещался что без проблем... Или же признаёшь, что реализация в C# слабее?
G>Дальше можно не продолжать.
Я правильно понимаю, что это означает слив? )
G>твоем примеру бесконечно далеко до async\await.
Что-то ты вообще куда-то не туда полез. Async\await в C# без проблем умеет работать и в рамках одного потока и с несколькими (await Task.Run()). Аналогично Boost.Coroutine без проблем умеет работать и в рамках одного потока (собственно только это в ней и есть) и с несколькими (с несколькими строками дополнения, типа моих выше). Так что ситуация абсолютно симметричная.
Я показал пример, использующий работу именно с несколькими потоками, т.к. она наиболее интересна на практике. Однако точно так же можно было бы придумать и вариант со сменой источника данных на внутреннее асинхронный, которому уже не понадобились бы потоки.
Здравствуйте, gandjustas, Вы писали:
G>Наверное потому что async\await отлично работает как на клиенте, так и на сервере. А ты сделал менее эффективный пример, который и этом нифига не масштабируется.
Клиент или сервер — это не принципиально. Важно количество соединений. И если мы имеем дело с системой под большие нагрузки (множество соединений), то уж точно глупо брать async\await из C# — это мягко говоря не лучший вариант по производительности. Место async\await из C# как раз в фоновой обработке нажатий на кнопки и т.п. Причём желательно в варианте с запуском потоков.
G>Если ты начнешь масштабировать свой подход, то он начнет дико тормозить. А если подход нельзя масштабировать, то нафига он такой нужен?
Какое масштабировать подход? У нас кнопка на экране для пользователя. По её нажатию в фоне запускается некий процесс, результат которого потом выдаёт на экран. Какое нафиг масштабирование тут? ))) И кстати как раз для таких вещей системные потоки вполне оптимальны. Более того, как раз если мы попробуем реализовать это без системный потоков, а наш фоновый процесс будер производит какие-то реальные вычисления, то у нас именно из-за отсутствия потоков начнёт подтормаживать интерфейс...
G>Решить частную задачу по созданию асинхронности одной функции можно запустив её в отдельном потоке, дописав маршалинг вызовов в UI и получится меньше чем пляски с корутинами\шаблонами\макросами.
Ну собственно лично я действительно не вижу особых преимуществ от подобной линеаризации кода, что в .net, что в C++. Но если кому-то нравится, то почему бы и нет. И как мы видим C++ вариант при этом получается мощнее.
А так, конечно реальная потребность подобных вещей появляется только при реализации чего-то типа легковесных потоков. Но тут как раз .net вариант заметно слабее, т.к. уже становятся принципиальны накладные расходы.
G>А можно не выдумывать хрень и использовать IOCP, эффективнее на винде ниче пока не придумали. G>Вот только код будет не такой, как у тебя.
О, кстати... А можно потестировать и главное при этом более менее вернуться к темке (языку D). Я тут видел в учебнике по D забавную реализацию в несколько строчек как раз функции копирования на базе потоков взаимодействующих по модели акторов.
_>>Это была речь про эту http://www.rsdn.ru/forum/philosophy/5357968
задачку. Ты же обещался: "я напишу такой же на C# в 3 раза короче". Или уже всё, слив? )
G>Дык я тебе уже написал, примерно с тем же уровнем детализации.
Это где? Я не видел от тебя ни одного куска кода.
G>Еще раз повторю — все изменения только в дописывании async\await.
Дописывание куда? По условиям задачи мы должны использовать существующий библиотечный код. Т.е. его нельзя модифицировать или переписывать.
G>Или давай компилируемый код, я тот же результат на C#, будет МИНИМУМ в 3 раза короче, даже если считать только значимый код.
Ты покажи хоть какой-нибудь код для начала. А то пока после всего своего пафоса на словах и полного отсутствие результата в делах ты выглядишь сам понимаешь как...
Здравствуйте, gandjustas, Вы писали:
G>Думаю стоит глянуть на Mono и Xamarin, перед тем как толкать такие утверждения. Сейчас спектр систем, где заработает код на C#, примерно такой же, как у java и у обоих гораздо шире, чем у C++.
С учётом того, на чём написаны сами .net, mono, java, эта фраза звучит особенно пикантно. Видимо здесь присутствует какая-то магия. )))
Здравствуйте, alex_public, Вы писали:
I>>Ты как то особенным образом понимаешь асинхронщину. В общем случае переписывать надо не из за дотнета, а из за того, что есть некоторое разделяемое состояние.
_>Не, переписывать надо исключительно из-за особенностей реализации await/async в .net.
Судя по примером ниже, это утверждение ты не смог обосновать.
I>>Вот простой пример _>
I>>function(){
I>> var value = read();
I>> write(next(value));
I>> }
I>>
_>Ты что-то всё путаешь. Всё зависит от того, как реализованы read и write. А точнее в каких потоках их можно вызывать.
Опаньки ! "переписывать надо исключительно из-за особенностей реализации await/async в .net"
И одновременно, оказывается, дотнет ни при чем, а всё зависит от особенностей реализации. Браво !
_>1. И read и write можно вызывать только в изначальном потоке. Тогда вообще ничего сделать нельзя и функция обречена быть синхронной.
Это неверно. Сделать можно и в С++ и в C# — переписывая функцию. Ты забыл, что мы про асинхронщину ?
_>2. И read и write можно вызывать в любых потоках. Тогда вообще всё просто и не нужны все эти хитрости типа await/async. Вот корректный асинхронный код: _>
_>thread([]{
_> auto value=read();
_> write(next(value));
_>}).detach();
_>
Ровно такой способ доступен в .Net Или ты хотел сказать, что в .Net нельзя фукнции запусать в отдельных потоках ?
_>А если нам требуется максимальное быстродействие и read и write относятся к разным устройствам, то можно вообще завести 2 независимых потока со своими буферами и синхронизацией (например через обмен сообщений по модели акторов). Но здесь уже понятно что не обойтись без модификации кода.
Опаньки — снова переписывать надо и там и там.
_>3. Смешанный вариант. Допустим read можно в любых потоках, а write только в изначальном. И только вот тут нам становятся нужны обсуждаемые хитрости. В C++ варианте я просто подменю функцию read на свою, содержащую вызов await_async([]{return read();}), и тогда напишу просто: _>
_>async_code(
_> auto value=read();
_> write(next(value));
_>)
_>
И получаешь нарушение инварианта.
_>В C# всё тоже самое, за исключением того, что обязательно требуется менять указанный код (добавить await). Причём менять надо не только его, но и весь стек вызова (добавить async).
Я шота смотрю, ты показал совсем не то, что декларировал
Здравствуйте, alex_public, Вы писали:
_>Ну я собственно это и имел в виду. Т.е. не принципиально ui это поток или нет (я просто называю так для краткости), главное что продолжение исполняется в том же потоке, который и инициировал асинхронный вызов. Вот в таком использование смысл имеется. А вот вариант, когда мы продолжим исполнение в каком-то произвольном пуле потоков (про что и писал gandjustas), уже на мой взгляд не приносит никакой пользы.
Наоборот. Когда исполнение уходит в другой поток, совершенно незачем придумывать для этго какие то особенные формы вызова функций, наводе thread( ля ля ля)
То есть, независимо от диспетчеризации, код выглядит одинаково. В С++ это не получится
2. С помощью корутин решаются такие задачи, которые не под силу C# await. И не надо разводить демагогию на тему "это не нужно/это редко встречается".
Это никакая не демагогия. Абстрактные рассуждения о мощности языка без рассмотрения реальных сценариев никому не интересны, это просто "разговоры о прекрасном"
С помощью ассемблера например решаются такие задачи, которые даже в С++ не под силу. Однако ассемблер это почему то шаг назад
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В этом случае если внутри "stream >> x" произойдёт yield, то инварианты могут быть поломаны. Но, если есть такой код — то ты его и на обычных потоках не сможешь запустить, корутины тут не причём
И этот сценарий встречается практически везде, когда имеешь дело с асинхронным кодом.
Здравствуйте, Ikemefula, Вы писали:
EP>>2. С помощью корутин решаются такие задачи, которые не под силу C# await. И не надо разводить демагогию на тему "это не нужно/это редко встречается". I>Это никакая не демагогия. Абстрактные рассуждения о мощности языка без рассмотрения реальных сценариев никому не интересны, это просто "разговоры о прекрасном"
Stackful coroutine мощнее — и это факт. А реальные примеры я уже показал
Здравствуйте, Ikemefula, Вы писали:
EP>>В этом случае если внутри "stream >> x" произойдёт yield, то инварианты могут быть поломаны. Но, если есть такой код — то ты его и на обычных потоках не сможешь запустить, корутины тут не причём I>И этот сценарий встречается практически везде, когда имеешь дело с асинхронным кодом.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>В этом случае если внутри "stream >> x" произойдёт yield, то инварианты могут быть поломаны. Но, если есть такой код — то ты его и на обычных потоках не сможешь запустить, корутины тут не причём I>>И этот сценарий встречается практически везде, когда имеешь дело с асинхронным кодом.
EP>Выше
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>2. С помощью корутин решаются такие задачи, которые не под силу C# await. И не надо разводить демагогию на тему "это не нужно/это редко встречается". I>>Это никакая не демагогия. Абстрактные рассуждения о мощности языка без рассмотрения реальных сценариев никому не интересны, это просто "разговоры о прекрасном"
EP>Stackful coroutine мощнее — и это факт. А реальные примеры я уже показал
Здравствуйте, Ikemefula, Вы писали:
I>Опаньки ! "переписывать надо исключительно из-за особенностей реализации await/async в .net" I>И одновременно, оказывается, дотнет ни при чем, а всё зависит от особенностей реализации. Браво !
Не, не так. Есть функции которые можно преобразовать в асинхронные без переписывания, а есть такие, которые нельзя. А вот .net заставляет нас переписывать любые, т.к. требует раскидывания async по всему стеку вызова.
I>Это неверно. Сделать можно и в С++ и в C# — переписывая функцию. Ты забыл, что мы про асинхронщину ?
Переписывая, естественно что угодно можно сделать. )
I>Ровно такой способ доступен в .Net Или ты хотел сказать, что в .Net нельзя фукнции запусать в отдельных потоках ?
Я хотел сказать, что и в .net и в C++ модель await/async в общем то не так уж и нужна. ))) По сути это сахар на достаточно специфическую ситуацию. Собственно мы это уже обсуждали в той старой темке.
I>И получаешь нарушение инварианта.
С чего бы это? Там выполнение будет строго последовательным, просто разделённым на два потока.
был пример gevent, где этого не было. Это по твоему какой-то редкий случай? I>Да, это редкий случай. Патчить можно и в джаве, и в дотнете, при чем без особых затруднений.
Здравствуйте, Ikemefula, Вы писали:
I>Наоборот. Когда исполнение уходит в другой поток, совершенно незачем придумывать для этго какие то особенные формы вызова функций, наводе thread( ля ля ля) I>То есть, независимо от диспетчеризации, код выглядит одинаково. В С++ это не получится
Ага, только это у нас и так шло выполнение в фоновом потоке. Соответственно непонятно зачем вообще плодить новый поток. Разве что потому что системке так удобнее (у неё нет диспечеризации в старый не ui поток)...
Здравствуйте, Ikemefula, Вы писали:
EP>>Stackful coroutine мощнее — и это факт. А реальные примеры я уже показал I>А ассемблер еще мощнее. И что с того ?
Вот это:
2. С помощью корутин решаются такие задачи, которые не под силу C# await. И не надо разводить демагогию на тему "это не нужно/это редко встречается".
Я писал не тебе. artelk, как впрочем и gandjustas , по всей видимости не знали/не понимали что корутины мощнее. (впрочем и до тебя это страниц сорок доходило)
Здравствуйте, gandjustas, Вы писали:
Pzz>>C# работает только на венде, а все практические реализации Явы обладают красотой и грациозностью бегемота, пасущегося на лугах Страны Неограниченных Ресурсов. G>Думаю стоит глянуть на Mono и Xamarin, перед тем как толкать такие утверждения. Сейчас спектр систем, где заработает код на C#, примерно такой же, как у java и у обоих гораздо шире, чем у C++.
Моно — это пионерская поделка, годящаясь только на то, чтобы изготавливать пионерские поделки. Существенной проблемой при этом является то, что пионеры не в состоянии понять, что кроссплатформенные пионерские поделки надо тестировать на всех платформах, а не только на любимом компьютере разработчила. Поэтому даже для изготовления кроссплатформенных пионерских поделок моно не годится. А пионерские поделки под венду проще все же делать, используя родные для венды средства.
В этой связи приходится признать, что единственное применение моно заключается в том, что пионеры могут с умным видом заявлять в форумах, что C# подходит для кроссплатформенной разработки.
Pzz>>Кросплатформенный язык общего назначения типа "си с классами", не страдающий при этом врожденной склонностью к онкологическим заболеваниям, безусловно, нужен. G>Практика показывает что эту нишу занял javascript.
Яваскрипт занял нишу "хотим писать скрипты-плагины, но не на питоне". Кроме того, в силу политических, а не технических причин, явяскрипт имеет весьма специфические отношения с некоторыми платформами, такими, как веб-программирование (в основном на стороне клиента), и т.п.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, gandjustas, Вы писали:
G>>Читал, а толку то? Этот подход решает очень узкую задачу — асинхронное чтение буковок. Это можно и с меньшим количеством кода сделать. G>>На обобщенный метод превращения синхронного кода в асинхронный не тянет.
EP>std::getline тут стандартная, не модифицированная. Точно также можно протащить yield и через любую другую функцию
Да, вот только надо очень хорошо понимать как работает эта функция. К счастью для переписывания синхронного кода в асинхронный в .NET не надо разбираться как он внтури устроен. Можно просто базвоые методы, которые делают IO сделать async, а дальше следуя руганиям компилятора добавить async\await во все методы выше по цепочке вызовов.
EP>>>Что значит особый случай? Точно также можно завернуть tcp_stream. G>>Надо очень хорошо знать как код работает внутри, чтобы делать такую асинхронность. EP>Есть любая асинхронная функция которая принимает continuation/.then — мы ей передаём в этот continuation код с yield-ом внутри, что механически превращает остаток нашей функции в продолжение.
Пример давай.
G>>А как комбинировать такие асинхронные вызовы не то что не очевидно, а вообще непонятно как. EP>Ты о чём?
Напрмиер так:
у тебя есть асинхронные функции f1 и f2, внтури они делают какой-то IO. Тебе нужно написать функцию f3, которая вызывает f1 и f2 параллельно, ждет их завершения и вызывает асинхронную операцию.
Реальное применение такой функции — сервис поиска авиабилетов. Он обращается параллельно к десяткам перевозчиков, получает данные, выбирает лучшие варианты, отдает клиентам. Естественно это hiload сервис, который не может позволить себе создавать потоки.
EP>>>При этом код использующий этот поток не поменяется, а в случае с C# await — нужно будет патчить весь call-stack G>>А зачем это делать? Преобразование синхронного кода в асинхронный — механическая операция, легко автоматизируется при желании. Я даже для стримов на roslyn такое переписывание делал.
EP>С такими же рассуждениями можно прийти к мысли что и yield, и await/async не нужны
Практика то показывает что нужны. Причем тут рассуждения?
То что ты считаешь что нужно патчить call-stack — вывод, основанный на неверной посылке.
EP>>>Причём большую часть boilerplate'а необходимого для заворачивания в корутины, легко вынести в библиотеку G>>Почему до сих пор никто не сделал? Видимо не так просто, ибо более чем востребовано в наше время.
EP>Как это никто не сделал? Раз, два, да даже возьми хоть мой пример реализации await
(это при том что я сам практически не работаю ни с каким io).
Без асинхронного IO это все смысла не имеет. Покажи пример с асинхронным IO.
В мире есть два источника асинхронности — люди и IO (на самом деле еще и таймеры, но они не отличаются от людей). Все остальное может и должно выполняться синхронно.
Для действия людей уже есть события. А для IO есть IOCP или аналогичные механизмы в других ОС.
Основная проблема в том, что IOCP и другие механизмы не сохраняют стек, поэтому придется значительно извратиться чтобы на это натянуть stackfull coroutines.
G>>>>Кроме того все это выполняется через глобальную переменную. Запустить два таких считывания уже не выйдет. EP>>>Это минимальный пример показывающий как вызов std::getline может работать с асинхронным потоком. G>>Проблема в том, что они показывает только вызов std::getline. Покажи как сделать тоже самое с вводом-выводом на IOCP. EP>>>Если будет async_tcp_stream — то будет хоть 100k соединений G>>Для начала тебе надо будет async io реализовать на IOCP.
EP>Ты мне предлагаешь реализовать свои обвёртки поверх голого IOCP? Зачем?
Без асинхронного IO все что ты пишешь не имеет смысла. Вообще.
Оно приведет только к деградации производительности.
Ты вообще представляешь как медленно будет работать твой пример с getline на реальном файле?
Опубликуешь результаты забегов? При этом масштабирования такой подход не добавил. Ты не сможешь также запустить 100500 чтений файлов и выйграть хоть что-то.
G>>>>Ты считаешь что такое "решение" способно тягаться с async\await в C#? EP>>>await-like синтаксис легко реализуется поверх корутин
, только получается намного мощнее, так как не ограничен одним уровнем. G>>Каким одним уровнем? ты о чем?
EP>О том, что для того чтобы сделать yield с самого низа callstack'а на самый вверх, тебе придётся дублировать и модифицировать каждый уровень. Причём эти уровни могут находится в библиотеках к которым нет доступа.
В смысле "нет доступа" ?
Если библиотеки — "черный ящик", то и твой подход не поможет, потому что требует знать как внутри работа устроена.
Если у тебя таки есть доступ к исходникам, то кто мешает сделать ctrl+c-ctrl+v и добавить async\await?
Кроме того в .NET код можно вытащить и из скомпилированных бинарников, а отличие от...
G>>>>А вот ты на C# await повторить пример с getline-like никак не сможешь. Разве не очевидно что мощнее G>>А зачем его повторять? Я же говорю что просто дописываешь async\await где можно код становится асинхронным. Даже понимать не надо как код работает.
EP>У тебя нет кода std::getline (или аналога) — куда ты там собрался дописывать await?
Если тебя нет когда getline, то как ты написал свой код? Он же полностью базируется на знании устройства getline, значит код у тебя есть.
