Т.е. распараллелить все. Задачи taskR1, taskR2 выполняются параллельно, в то время как bar продолжает работать, выполняя M1() и M2().
A>>TcpStream — это какой-то специальный stream, который периодически делает yield? EP>Да, только не периодически, а по необходимости. Внутри у него что-то типа: EP>
EP>async_read(connection, buffer, /* completion callback: */ [coro]{ coro.resume(); } );
EP>coro.yeild(); // "sleep", will be awakened by completion callback
EP>
EP>Причём у него интерфейс как у обычного блокирующего потока, без намёков на асинхронность, поэтому он и совместим с std::istream.
Понятно. Т.е. нужно не забывать, что инстанцировать нужно именно специальные стримы, которые "знают" о нашем трюке.
А как быть с задачами, которые вообще со стримами не работают?
Здравствуйте, alex_public, Вы писали:
_>Вообще весьма симптоматично, что самым верным защитником управляемых языков и C# в частности, оказался не использующий C# на практике.
10 лет C# этого разве недостаточно ?
_>А всякие официальные пользователи C# типа gandjustas и прочих IT резко слились из темы, как только дело дошло до обсуждения конкретики. )))
Наверное им было скучно по сто раз одно и то же объяснять.
Здравствуйте, Ikemefula, Вы писали:
I>Твои идейки распространяются на случай из двух трех короутин, где все и так само работает. Общий случай такой — высокоприоритетный поток вдруг начинает ожидать результат низкоприоритетного потока, а тот спит, потому что выполняются другие потоки. Что бы такое не возникало, нужен хороший шедулер и возможность сообщать шедулеру, где какой приоритет и кто чего ожидает. I>Кроме как расставить все руками у тебя ничего нет, правильно ?
Я же тебе сказал, если ты сам в состоянии управлять очередью исполнения кода в кооперативной многозадачности, то тебе не нужен никакой "приоритет".
I>От тебя было утверждение про некие гарантии. Хочу увидеть эти гарантии примером кода.
Еще раз сформулируй, гарантии чего именно. Пример кода я привел. Гарантий никогда нет. С async/await тоже, ес-но.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Тогда поясни — либо "их" это все таки несколько более узкий круг, чем заявлено, либо я не принадлежу к "более опытным разработчикам". V>>Угу, характерно, что упоминание конкретного примера, где точный тип обязателен, ты проигнорил... AVK>А ты умудрился проигнорить явно заданный вопрос, при этом ответить на сообщение, целиком состоящее из этого вопроса.
Столь несложная демагогия даже оскорбительна для почти 10-тилетнего оппонирования. )))
Я не вижу у тебя собсно вопроса по-существу, вижу несколько заранее подготовленных вариантов ответов, где подразумеваемый вопрос звучит так: "какой из предложенных мною вариантов ты выберешь?". Правильного среди них нет.
Здравствуйте, vdimas, Вы писали:
I>>Твои идейки распространяются на случай из двух трех короутин, где все и так само работает. Общий случай такой — высокоприоритетный поток вдруг начинает ожидать результат низкоприоритетного потока, а тот спит, потому что выполняются другие потоки. Что бы такое не возникало, нужен хороший шедулер и возможность сообщать шедулеру, где какой приоритет и кто чего ожидает. I>>Кроме как расставить все руками у тебя ничего нет, правильно ?
V>Я же тебе сказал, если ты сам в состоянии управлять очередью исполнения кода в кооперативной многозадачности, то тебе не нужен никакой "приоритет".
Нужен, в том то и дело. Одна короутина должна отработать пораньше, а другая может хоть пол-часа ждать.
I>>От тебя было утверждение про некие гарантии. Хочу увидеть эти гарантии примером кода.
V>Еще раз сформулируй, гарантии чего именно. Пример кода я привел. Гарантий никогда нет. С async/await тоже, ес-но.
Здравствуйте, artelk, Вы писали:
EP>>По смыслу, это примерно тоже самое, что и: EP>>
EP>>asyncTask<Result> bar(istream client1, istream client2)
EP>>{
EP>> var result = await foo(client1) + await foo(client2);
EP>> return result;
EP>>}
EP>>
EP>>Вызывающий поток(thread) не блокируется, а возвращается к другим задачам, например по event loop. A>Т.е. твоя реализация ограничена кооперативной многозадачностью поверх event loop?
Мой пример показывает то, чего на C# нельзя достичь.
A>Для async/await это лишь один из способов выполнения. A>А еще, то, что возвращается именно Task позволяет нам, например, написать так: A>
A>async Task<int> bar(client1, client2)
A>{
A> var taskR1 = foo(client1);
A> var taskR2 = foo(client2);
A> M1();
A> M2();
A> return await taskR1 + await taskR2;
A>}
A>
A>Т.е. распараллелить все. Задачи taskR1, taskR2 выполняются параллельно, в то время как bar продолжает работать, выполняя M1() и M2().
Точно такой же синтаксис оператора await можно получить с помощью stackful coroutine, только он будет мощнее, так как может yield'ить через много уровней, а не один.
A>>>TcpStream — это какой-то специальный stream, который периодически делает yield? EP>>Да, только не периодически, а по необходимости. Внутри у него что-то типа: EP>>
EP>>async_read(connection, buffer, /* completion callback: */ [coro]{ coro.resume(); } );
EP>>coro.yeild(); // "sleep", will be awakened by completion callback
EP>>
EP>>Причём у него интерфейс как у обычного блокирующего потока, без намёков на асинхронность, поэтому он и совместим с std::istream. A>Понятно. Т.е. нужно не забывать, что инстанцировать нужно именно специальные стримы, которые "знают" о нашем трюке. A>А как быть с задачами, которые вообще со стримами не работают?
Ещё раз, это конкретный пример инкапсуляции асинхронной логики таким образом, что много уровней клиентского кода могут и не догадываться об этом — на C# так не получится, послушай своего коллегу
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Мой пример показывает то, чего на C# нельзя достичь.
А надо ? Твой пример похож на "я и так могу".
A>>Т.е. распараллелить все. Задачи taskR1, taskR2 выполняются параллельно, в то время как bar продолжает работать, выполняя M1() и M2().
EP>Точно такой же синтаксис оператора await можно получить с помощью stackful coroutine, только он будет мощнее, так как может yield'ить через много уровней, а не один.
Это именно то чего делать ни в коем случае не нужно.
EP>Ещё раз, это конкретный пример инкапсуляции асинхронной логики таким образом, что много уровней клиентского кода могут и не догадываться об этом — на C# так не получится, послушай своего коллегу
одну из фишек stackful coroutine. artelk подумал что это едиственная фишка, на что я сделал пояснение.
A>>>Т.е. распараллелить все. Задачи taskR1, taskR2 выполняются параллельно, в то время как bar продолжает работать, выполняя M1() и M2(). EP>>Точно такой же синтаксис оператора await можно получить с помощью stackful coroutine, только он будет мощнее, так как может yield'ить через много уровней, а не один. I>Это именно то чего делать ни в коем случае не нужно.
Можно без проблем ограничить одним уровнем, а можно и не ограничивать.
EP>>Ещё раз, это конкретный пример инкапсуляции асинхронной логики таким образом, что много уровней клиентского кода могут и не догадываться об этом — на C# так не получится, послушай своего коллегу
. EP>>Очевидно, что так можно инкапсулировать что угодно, а не только стримы, в том числе реализовать более мощный аналог await I>аналог await это хорошо, а если "через много уровней", то хуже некуда, хаос в коде гарантирован.
При использовании await'а, часто вырастают "вынужденные" цепочки await'ов/async'ов вверх по call stack'у — об этом говорится во многих туториалах по await.
Имея возможность "через много уровней", можно по необходимости ввести ограничение на "один уровень".
Будет ли хаос при использовании "через много уровней" — сходу сказать не могу, ибо не использовал. Рассказы про "хаос" вообще окружают каждую фишку которая даёт что-то в обмен на потерю контроля.
function pointer, virtual function, overloading — "хаос, неизвестно что вызывается"
type inference, auto, template argument deduction — "хаос, неизвестно какие типы, и вообще duck typing" (даже в этой теме успели это пережевать)
Как показывает история, зачастую все эти страхи от банального blub-парадокса и инерции
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>При использовании await'а, часто вырастают "вынужденные" цепочки await'ов/async'ов вверх по call stack'у — об этом говорится во многих туториалах по await. EP>Имея возможность "через много уровней", можно по необходимости ввести ограничение на "один уровень".
Правильно быть в курсе, что ты в такой вот цепочке.
EP>Будет ли хаос при использовании "через много уровней" — сходу сказать не могу, ибо не использовал. Рассказы про "хаос" вообще окружают каждую фишку которая даёт что-то в обмен на потерю контроля. EP>function pointer, virtual function, overloading — "хаос, неизвестно что вызывается" EP>type inference, auto, template argument deduction — "хаос, неизвестно какие типы, и вообще duck typing" (даже в этой теме успели это пережевать) EP>Как показывает история, зачастую все эти страхи от банального blub-парадокса и инерции
Ты лучше посмотри насколько "широко" используются файберы. Это собтсвенно демонстрация никчемности твоих короутин.
Здравствуйте, Ikemefula, Вы писали:
EP>>Будет ли хаос при использовании "через много уровней" — сходу сказать не могу, ибо не использовал. Рассказы про "хаос" вообще окружают каждую фишку которая даёт что-то в обмен на потерю контроля. EP>>function pointer, virtual function, overloading — "хаос, неизвестно что вызывается" EP>>type inference, auto, template argument deduction — "хаос, неизвестно какие типы, и вообще duck typing" (даже в этой теме успели это пережевать) EP>>Как показывает история, зачастую все эти страхи от банального blub-парадокса и инерции
I>Ты лучше посмотри насколько "широко" используются файберы. Это собтсвенно демонстрация никчемности твоих короутин.
Ты предлагаешь неочевидный инструмент, который будут делать чтото интересное в глубоком стеке который и так непонятно, как контролировать.
Сейчас другой тренд — во все языки проникают всякие монады и разные вкусные вещи для декларативного кода. Эта хрень позволяет ужать стек вызовов до безобразия.
Здравствуйте, Ikemefula, Вы писали:
I>10 лет C# этого разве недостаточно ?
Что-то по отсутствию знания базовых примитивов многопоточности эти 10 лет совсем не чувствуются... )
I>Наверное им было скучно по сто раз одно и то же объяснять.
Если бы. На деле там были громкие крики в стиле "а вот фиг вы сделаете такое на C++". И соответственно после того, как бы представлен код делающий именно это самое, мгновенный тихий слив из темки...
_>А всякие официальные пользователи C# типа gandjustas и прочих IT резко слились из темы, как только дело дошло до обсуждения конкретики. )))
не, я просто в отпуск уехал, а когда вернулся стало лениво все читать. Но я так понял что до сих пор никто не показал пример GUI Фреймворка с интегрированными stickful coroutines, так что все примеры ни о чем.
Поправьте, если я ошибаюсь.
_>P.S. А Ikemefula хотя и дико упёртый, но в любом случае достоин уважения. )
ИМХО он может до бесконечности спорить на любую тему.
OFF: не пишу сюда как правило — теоритики собираются
Но, так как в чужом коде постоянно приходиться разбираться, то замечу — если человек поверхностно глянул, а потом проект "спустил" заказчику, то в той "армии" даже дубы не растут, Вы не заставляете себя вдуматься, что конкретный код делает... А плюсы заставляют...
P.S. Не ради флэйма... я могу, если трезвый и по-английский свободно, и на русском-командо-матерном и разговаривать и читать, и ту же Аду читать с вместе Паскакалем Остальное просто расслабляет программерский контингент, особенно сдача проекта вовремя...
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, vdimas, Вы писали:
I>>>Твои идейки распространяются на случай из двух трех короутин, где все и так само работает. Общий случай такой — высокоприоритетный поток вдруг начинает ожидать результат низкоприоритетного потока, а тот спит, потому что выполняются другие потоки. Что бы такое не возникало, нужен хороший шедулер и возможность сообщать шедулеру, где какой приоритет и кто чего ожидает. I>>>Кроме как расставить все руками у тебя ничего нет, правильно ?
V>>Я же тебе сказал, если ты сам в состоянии управлять очередью исполнения кода в кооперативной многозадачности, то тебе не нужен никакой "приоритет".
I>Нужен, в том то и дело. Одна короутина должна отработать пораньше, а другая может хоть пол-часа ждать.
Для этого не нужен никакой числовой "приоритет", если мы все еще говорим о зависимых друг от друга короутинах, т.е. обладаем информацией об этой зависимости и о способе получать мгновеннную прикладную картинку востребованности ресурсов. Независимые же короутины вполне можно разносить по разным аппаратным потокам.
V>>Еще раз сформулируй, гарантии чего именно. Пример кода я привел. Гарантий никогда нет. С async/await тоже, ес-но. I>Ты сам вспомни, чего ты вещал про гарантии
Гарантии в обоих языках даются системой типов. Ты же попросил меня отличить синхронный вызов от асинхронного. Сорри, но в C# они отличаются лишь синтаксическим сахаром. Я вполне могу в действующей системе типов расписать происходящее без await.
Здравствуйте, alex_public, Вы писали:
I>>10 лет C# этого разве недостаточно ?
_>Что-то по отсутствию знания базовых примитивов многопоточности эти 10 лет совсем не чувствуются... )
Про базовые примитивы многопоточности здесь ни в одном месте речи не было Но вообще ты прав, я многопоточностью занимался совсем немного и в основном по собтсвенной инициативе.
I>>Наверное им было скучно по сто раз одно и то же объяснять.
_>Если бы. На деле там были громкие крики в стиле "а вот фиг вы сделаете такое на C++". И соответственно после того, как бы представлен код делающий именно это самое, мгновенный тихий слив из темки...
Ваши короутины это плак по тем возможностям которые были утеряны вместе с ассемблером.
На ассемблере это детский лепет, уровня лабораторной задачи на втором семестре ассемблера. Скажем вытесняющая и кооперативная многозадачность это примерно уровень курсовой работы. Щас вот функционалисты ищут способы оптимизации хвостовой рекурсии, а в ассемблере это само работало — continuations, рекурсия на бесконечном стеке и тд и тд и тд.
И кстати говоря, все согласуется с парадоксом Блаба — не хочешь учить ассемблер, значит пишешь на Блабе
Здравствуйте, vdimas, Вы писали:
I>>Нужен, в том то и дело. Одна короутина должна отработать пораньше, а другая может хоть пол-часа ждать.
V>Для этого не нужен никакой числовой "приоритет", если мы все еще говорим о зависимых друг от друга короутинах, т.е. обладаем информацией об этой зависимости и о способе получать мгновеннную прикладную картинку востребованности ресурсов. Независимые же короутины вполне можно разносить по разным аппаратным потокам.
Для двух-трех короутин это работает, да.
I>>Ты сам вспомни, чего ты вещал про гарантии
V>Гарантии в обоих языках даются системой типов. Ты же попросил меня отличить синхронный вызов от асинхронного. Сорри, но в C# они отличаются лишь синтаксическим сахаром. Я вполне могу в действующей системе типов расписать происходящее без await.
Весь твой с++ это просто сахар для ассемблера. Вобщем, раз ты ничего не можешь вспомнить про гарантии, то можно и закончить.
Здравствуйте, Figaro, Вы писали:
F>Но, так как в чужом коде постоянно приходиться разбираться, то замечу — если человек поверхностно глянул, а потом проект "спустил" заказчику, то в той "армии" даже дубы не растут, Вы не заставляете себя вдуматься, что конкретный код делает... А плюсы заставляют...
Что же ты на ассемблере не пишешь, он так заставит думать, не передать словами, только и будешь этим заниматься ? Что, парадокс Блаба мешает ?
Здравствуйте, gandjustas, Вы писали:
_>>А всякие официальные пользователи C# типа gandjustas и прочих IT резко слились из темы, как только дело дошло до обсуждения конкретики. )))
G>не, я просто в отпуск уехал, а когда вернулся стало лениво все читать. Но я так понял что до сих пор никто не показал пример GUI Фреймворка с интегрированными stickful coroutines, так что все примеры ни о чем.
А может тебе сразу операционную систему накидать на коленке ?
G>Поправьте, если я ошибаюсь.
Все что надо уже давно показано.
_>>P.S. А Ikemefula хотя и дико упёртый, но в любом случае достоин уважения. ) G>ИМХО он может до бесконечности спорить на любую тему.
На любую не умею, в отличие от тебя я не лезу туда, где ничего не знаю. Ты подрываешь авторитет дотнетчиков своими аргументами
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
_>>>А всякие официальные пользователи C# типа gandjustas и прочих IT резко слились из темы, как только дело дошло до обсуждения конкретики. )))
G>>не, я просто в отпуск уехал, а когда вернулся стало лениво все читать. Но я так понял что до сих пор никто не показал пример GUI Фреймворка с интегрированными stickful coroutines, так что все примеры ни о чем.
I>А может тебе сразу операционную систему накидать на коленке ?
Если интеграция stackful coroutines с гуйней сравнима с написанием ОС, то это конечно говорит в пользу C++
G>>Поправьте, если я ошибаюсь. I>Все что надо уже давно показано.
А ссылку не модно?
_>>>P.S. А Ikemefula хотя и дико упёртый, но в любом случае достоин уважения. ) G>>ИМХО он может до бесконечности спорить на любую тему. I>На любую не умею, в отличие от тебя я не лезу туда, где ничего не знаю. Ты подрываешь авторитет дотнетчиков своими аргументами
Практика показывает обратное, но к данной теме отношения не имеет.
