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

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

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

BZ>как я уже говорил, есть во первых вариант с потоками/файберами и т.п. во вторых, для любого компилируемого языка (без VM) можно сделать крошечную ассемблерную библиотечку, которая создаёт и переключает стёки. а для языка с VM такое моджно сделать на уровне VM, а наружу выставить в виде API

У балаболов всегда все легко и просто. И виртуальную машину с сопрограммами они за денек сделают, и компилятор напишут за два часа. Куда только oracle и ms смотрят, когда есть такие ценные кадры. Глядишь и правильные стековые сопрограммы в jvm появились бы через три дня после того, как Булат заступит на должностью

BZ>твоя проблема в том что ты не знаешь ничего кроме своего C# и начинаешь рассуждать о других языках

Ты про erlang и про зеленые потоки точно также узнал, как и про то, что я пишу на С#?

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

LP>У балаболов всегда все легко и просто.

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

LP>И виртуальную машину с сопрограммами они за денек сделают,

было дело, я пока был в отпуске, сообразил как сделать сопрограммы на setjmp (а мне их в C страшно не хватало!), потом приехал залез в справку по борланду и там в статье по setjmp написано — их можно использовать для сопрограмм. так что это вполне штатная фича была и библиотеку я позже таки сделал

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

LP>Как без корутин сделать такой код
LP>

LP>resp = await cast(actor, msg);//происходит возврат управления из функции, актор готов принимать сообщения
LP>//Отсюда выполнение продолжится, когда придет ответ на запрос
LP>process(resp);
LP>

Вот это как раз и есть классическая линеаризация асинхронного кода. Только вот она мягко говоря не всегда нужна (а я бы вообще предложил не пользоваться этим инструментом, только затрудняющим понимание кода (того что реально происходит под капотом, скажем большинство C# программистов даже близко не представляют себе что там стоит внутри за async/await)).

Начнём с того, что в очень многих случаях process может исполняться внутри самого асинхронного кода и соответственно никаких подобных проблем не возникает. Кстати это тоже вполне укладывается в модель акторов — молча отработал (не работая с общей памятью) и умер. Исключений, когда process нельзя вызывать в асинхронном коде, на самом деле не много. С ходу в голову приходят:

1. GUI (работа с ним из других потоков обычно запрещена). Однако в таком случае родительский код, исполняющий process — это как раз GUI поток и соответственно уже имеет встроенную (и интенсивно использующуюся, причём с помощью мощных библиотечных инструментов, реализующих не просто конечные автоматы, а сложную надстройку над ними с подписками и т.п., обычно на базе ООП) очередь сообщений. Соответственно здесь у нас по сути сама собой образуется неявная модель акторов (ну если конечно асинхронный код не будет работать с общей памятью). Это в точности мой пример. И сопрограммы тут, как видно, не обязательны.

2. Распараллеливание вычислений. Когда мы для ускорения хотим выполнить некий код (например цикл) сразу в нескольких потоках, а результаты соответственно собираем в родительском коде для дальнейшей обработки. Здесь естественно никакие модели акторов не подходят. Для таких целей есть готовые удобные инструменты типа openmp и т.п. бесчисленные библиотеки с реализацией parallel_for и т.п. Реализуется это всё внутри через банальную блокировку до тех пор, пока не будут готовы все данные из запущенных веток. Сопрограммы здесь тем более не нужны.

3. Использование асинхронного IO. В этом случае асинхронный код вообще нам не принадлежит. Но при этом нам доступны соответствующие callback'и (в этом случае самые классические), которые легко упаковываются в удобные структуры. Смотри например Boost.Asio. Опять же нет никакой обязательной потребности в сопрограммах.

Какие ещё будут примеры асинхронного кода, где крайне необходима линеаризация?)

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

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

LP>>У балаболов всегда все легко и просто.

BZ>слушай, я не люблю всю эту машинерию с модераторами. когда я говорю о твоих скромных познаниях вне C# — я говорю о технических аспектах, я например точно так же не знаю C#. когда ты начинаешь разбрасываться обидными словами — это уже нехорошо

Ну могу тебя обрадовать — С# я тоже не знаю, все мои знания о нем исчерпываются примерами на форумах. На тему обидных слов — люди, которые утверждают, что могут легко сделать то, что не сделли две огромные корпорации за двадцать лет. не вызывают уважения. Если тебя это задело — прошу прощения.

LP>>И виртуальную машину с сопрограммами они за денек сделают,

BZ>было дело, я пока был в отпуске, сообразил как сделать сопрограммы на setjmp (а мне их в C страшно не хватало!), потом приехал залез в справку по борланду и там в статье по setjmp написано — их можно использовать для сопрограмм. так что это вполне штатная фича была и библиотеку я позже таки сделал

Рад за тебя (серьезно, без шуток).

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

S>Кэп #2: таймауты, тек. позиция, seek, асинхронное чтение, тип потока (чтение/запись/оба), flush etc. Если этого нет из коробки, то на ровном месте придётся городить тонну костылей. Для каждого из мест использования.

В чём проблема реализовать асинхронное чтение в IStream::Read с помощью async/await?

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

_>>Что ещё за callback через очередь сообщений? ) Ну да ладно, пускай будет для простоты обсуждения. )))
LP>Очередь — это особенность реализации. К самой концепции callback-ов не имеющая отношения.
LP>

LP>In computer programming, a callback is a piece of executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at some convenient time.

И какой конкретно код передаётся для последующего вызова в моём примере? )

_>>А можно увидеть определение актора, которое обязывает нас принимать произвольное число непонятных сообщений? ) С чего вообще актор обязан принимать какие-то сообщения? Если скажем ему для работы не нужны никакие дополнительных данные...
LP>Ну да, в hellow world они действительно красивые и причесанные. Только вот в реальной практике почему-то 90 процентов акторов выглядят именно так, как я показал.

Как я уже говорил, кривыми руками можно сделать говнокод из любого инструмента, даже самого идеального. )

LP>Вообще, когда актору требуется получить что-то от другого актора для обработки сообщения — тривиальнейшая ситуация. Это известно любому, кто хоть немного сталкивался с акторами.

Естественно. Но это не является обязательным требованием на право называться актором.

И кстати говоря, если даже актор и получает некие данные в виде сообщения, то это всё равно не приведёт к появлению конечного автомата.

_>>Конечный автомат нужен, если плодить сложные акторы, выполняющих множество разных ролей. Если же делать по актору на каждую роль, то никакие конечные автоматы не нужны.
LP>Настолько не нужны, что даже разработчики akka рекомендуют делать акторы через автоматы, поддержка которых сделана прямо в akka ))

Нууу так akka — это же кажется решение из мира Java? ) Там всегда любили наворотить монструозные обобщённые решения, дикие фреймворки с кучей никчемных классов и т.п. )))

_>>Сопрограммы используются для линеаризации асинхронного кода. Не важно какого происхождение. На базе системных потооков или лёгких потоков или вообще из асинхронного IO. По твому получается, что любой нелинеризованный асинхронный код обязательно содержит конечный автомат. Это весьма забавное утверждение. )))
LP>Ну, это ты хорошо за меня придумал. Это где из моих слов выходит такое?

Так ты же сам писал, что или сопрограммы или конечный автомат. )

_>>Так а почему оно не правильное, если ты сам согласился, что получился удобный код? )
LP>Код получился удобным не в акторе. Эдак можно каждый асинхронный обработчик называть актором.

Если это отдельно исполняющаяся сущность, не работающая с общей памятью, а передающая данные через сообщения, то почему бы и нет? )

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

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

LP>>Как без корутин сделать такой код
LP>>

LP>>resp = await cast(actor, msg);//происходит возврат управления из функции, актор готов принимать сообщения
LP>>//Отсюда выполнение продолжится, когда придет ответ на запрос
LP>>process(resp);
LP>>

_>Вот это как раз и есть классическая линеаризация асинхронного кода. Только вот она мягко говоря не всегда нужна (а я бы вообще предложил не пользоваться этим инструментом, только затрудняющим понимание кода (того что реально происходит под капотом, скажем большинство C# программистов даже близко не представляют себе что там стоит внутри за async/await)).

А ты пробовал использовать async/await для реализации конечного автомата? Я пробовал и не раз (в яве, через библиотеку). Результат — кода стало в три раза меньше.

Почитай также здесь
http://docs.unity3d.com/ru/current/Manual/Coroutines.html

Сто процентов скриптов Юнити делаются при помощи "линеаризации асинхронного кода".
Сто процентов скриптов на Unreal Engine делаются при помощи "линеаризации асинхронного кода".

Мужики делают что-то не так?

_>Начнём с того, что в очень многих случаях process может исполняться внутри самого асинхронного кода и соответственно никаких подобных проблем не возникает. Кстати это тоже вполне укладывается в модель акторов — молча отработал (не работая с общей памятью) и умер. Исключений, когда process нельзя вызывать в асинхронном коде, на самом деле не много. С ходу в голову приходят:

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

Есть же пример, который я привел в корневом сообщении (последний)

1. Считаешь ты этот пример легким и читаемым по сравнению с синхронным случаем?
2. Считаешь ты этот пример легким и читаемым по сравнению с async/await?

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

MX>В чём проблема реализовать асинхронное чтение в IStream::Read с помощью async/await?
Проблема в том, что async\await не знает о внутренностях потока и о реальном API, которое используется для асинхронного чтения-записи (напомню, асинхронность достигается не запуском отдельного потока, а калбэками поверх IOCP).

Это api спрятано за теми самыми "легаси" BeginRead/Write. BeginXyzAsync — это просто сахар и в принципе без него спокойно можно обойтись. Как это делалось в четвёртом фреймворке, например.

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

LP>Ну могу тебя обрадовать — С# я тоже не знаю, все мои знания о нем исчерпываются примерами на форумах. На тему обидных слов — люди, которые утверждают, что могут легко сделать то, что не сделли две огромные корпорации за двадцать лет. не вызывают уважения. Если тебя это задело — прошу прощения.

опять тебя отсутствие занний подводит — есть куча реализаций сопрограмм и зелёных потоков в различных инетпретаторах (ruby, python, js) и в виде внешних библиотек. кто ж виноват что ты ни о чём кроме c# hype не слышал??

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

LP>Да нет, это ты приплел совершенно не в тему зеленые потоки и сейчас юлишь, пытаясь свести весь эрланг к ним.

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

LP>>>Тут нужно переключать не абы когда (как в случае c green threads в общем случае), а именно после отправки асинхронного сообщения, и возвращать управление после получения ответа на запрос.
BZ>>насколоько я понимаю, переключать нужно при ожидании ответа — если он ещё не готов. опять же советую тебе глядеть на green thread как разновдиность потоков вообще, просто более эффективно реализуемую.

LP>Чем это отличается это от того, что я написал?

ты написал что переключить моджно только в один момент — после отправки сообщения. я о том, что можно в любой оот отправки до получения результата и даже вообще не переключать, если второй работает параллельно на другом ядре. так что именно green threads, именно переключение в произвольный момент

LP>И с чего ты взял, что в эрланге все происходит именно так? Вон Мамут, который в отличие от тебя писал на эрланге, ничего подобного не приводит.

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

BZ>>а ты похоже всё пытаешься к своему миру C# свести, отсюда трудности

LP>К моему? Ну-ну. Я никогда не писал и ни планирую писать на С# и ссылаюсь на него лишь потому, что именно этот язык ввел понятия сопрограмм в мейнстрим и для многим именно мс-ская реализация является референсной.

ну перестань, а? в десятках языков это было, и организовано куда удобней чем stackless coroutines в C#, просто ты лично ни с чем иным не знаком. как мамут, честное слово

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

LP>И с чего ты взял, что в эрланге все происходит именно так? Вон Мамут, который в отличие от тебя писал на эрланге, ничего подобного не приводит.

вероятно, всё дело в черепе

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

_>>Вот это как раз и есть классическая линеаризация асинхронного кода. Только вот она мягко говоря не всегда нужна (а я бы вообще предложил не пользоваться этим инструментом, только затрудняющим понимание кода (того что реально происходит под капотом, скажем большинство C# программистов даже близко не представляют себе что там стоит внутри за async/await)).
LP>А ты пробовал использовать async/await для реализации конечного автомата? Я пробовал и не раз (в яве, через библиотеку). Результат — кода стало в три раза меньше.

Сопрограммы для реализации конечного автомата? ) Это что-то новенькое... ))) Если мне надо реализовать конечный автомат (именно его, а не какое-то параллельное исполнение), то я уже показал с помощью какого инструмента я буду его реализовывать. И вряд ли у тебя получится удобнее. )

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

LP>Почитай также здесь
LP>http://docs.unity3d.com/ru/current/Manual/Coroutines.html

Кстати, в C# с async/await вообще надо настороже быть. Потому как описываемое в данной темке поведение (с исполнением продолжения в изначальном потоке) там наблюдается только при условие (при дефолтных настройках), что изначальный поток — это тот самый главный GUI поток. Если же запустить подобный код просто в каком-то потоке, то продолжение будет исполняться в произвольном свободном потоке из пула (это может даже оказаться тот же самый поток, где исполнялся асинхронный код, только после кучи никчемных переключений), а не в родительском потоке. Что сводит к нулю всю возможную пользу от сопрограмм.

Собственно из этого сомнительного решения сразу видно под что они затачивали своё решения — как раз под аналог моего примера с GUI.

LP>Сто процентов скриптов Юнити делаются при помощи "линеаризации асинхронного кода".
LP>Сто процентов скриптов на Unreal Engine делаются при помощи "линеаризации асинхронного кода".
LP>Мужики делают что-то не так?

Да, да, миллион мух не может ошибаться. )))

_>>Начнём с того, что в очень многих случаях process может исполняться внутри самого асинхронного кода и соответственно никаких подобных проблем не возникает. Кстати это тоже вполне укладывается в модель акторов — молча отработал (не работая с общей памятью) и умер. Исключений, когда process нельзя вызывать в асинхронном коде, на самом деле не много. С ходу в голову приходят:
LP>process является локальным по отношению к данному актору. он работает с данными актора. Если все может сделать другой актор, то зачем нужен вообще _этот_ актор?

Актор нужен для параллельного исполнения задач. Но он не обязан при этом обязательно общаться с другими акторами. Собственно описываемые проблемы возникают только в случае необходимости возврата значения из асинхронного кода. Что далеко не всегда требуется. А в тех нескольких случаях, когда реально требуется, я привёл решения без всяких сопрограмм и конечных автоматом.

LP>Есть же пример, который я привел в корневом сообщении (последний)
LP>1. Считаешь ты этот пример легким и читаемым по сравнению с синхронным случаем?
LP>2. Считаешь ты этот пример легким и читаемым по сравнению с async/await?

Данный пример реализуется как раз 2-ой случай из моего описание (распараллеливание). И очевидно не требует для своей реализации ни сопрограмм, ни акторов, ни конечных автоматом. Достаточно банальной блокировки (future.get), что ты и продемонстрировал.

Однако если захотеть реализовать данный пример с помощью акторов (т.е. по сути заменить передачу возвращаемого значения с future на message), то практически ничего не изменится. Если конечно не притаскивать зачем-то никчемные (тут) конечные автоматы.

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

_>2. Распараллеливание вычислений. Когда мы для ускорения хотим выполнить некий код (например цикл) сразу в нескольких потоках, а результаты соответственно собираем в родительском коде для дальнейшей обработки. Здесь естественно никакие модели акторов не подходят. Для таких целей есть готовые удобные инструменты типа openmp и т.п. бесчисленные библиотеки с реализацией parallel_for и т.п. Реализуется это всё внутри через банальную блокировку до тех пор, пока не будут готовы все данные из запущенных веток. Сопрограммы здесь тем более не нужны.

как раз это далеко не всегда можно сделать на parallel_for. погляджи на TPL/TBB — там parallel_for предлагается для простых задач, а для более слодных есть граф выполнения, вполне в стиле акторов. вот тебе пример — архиватор:

первый поток обходит каталоги читает входные файлы
второй поток разбивает эти данные на сжимаемые куски
пул потоков выполняют задания на сжатие
потоки из того же пула выполняют задания на шифрование
послежний поток пишет готовые блоки в архив

соответственно реализовывается всё это графом сообщений, часть задач распараллеливается в пуле потоков, часть ограничена скоростью I/O и может работать через любые асинхронные средства

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

_>Сопрограммы для реализации конечного автомата? ) Это что-то новенькое... ))) Если мне надо реализовать конечный автомат (именно его, а не какое-то параллельное исполнение), то я уже показал с помощью какого инструмента я буду его реализовывать. И вряд ли у тебя получится удобнее. )

когда в этот конечный автомат входит текущая позиция в стёке вызовов, вряд ли получится удобней чем с сопрограммами. преимущество сопрограмм — в том что код формально линейный, запросили данные — ту же получили ответ. не знаю какой ты инструмент имеешь в виду, но удобней resp = await ask() вряд ли будет

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

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

_>>>Вот это как раз и есть классическая линеаризация асинхронного кода. Только вот она мягко говоря не всегда нужна (а я бы вообще предложил не пользоваться этим инструментом, только затрудняющим понимание кода (того что реально происходит под капотом, скажем большинство C# программистов даже близко не представляют себе что там стоит внутри за async/await)).
LP>>А ты пробовал использовать async/await для реализации конечного автомата? Я пробовал и не раз (в яве, через библиотеку). Результат — кода стало в три раза меньше.

_>Сопрограммы для реализации конечного автомата? ) Это что-то новенькое... ))) Если мне надо реализовать конечный автомат (именно его, а не какое-то параллельное исполнение), то я уже показал с помощью какого инструмента я буду его реализовывать. И вряд ли у тебя получится удобнее. )

Мда... Собственно, на это можно прекращать дискуссию, поскольку ты вообще не представляешь себе предмет обсуждения.

Ключевые тезисы: иерархический конечный автомат, уменьшение количества состояний автомата за счет автоматического запоминания текущей позиции в стеке

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

LP>Ключевые тезисы: иерархический конечный автомат, уменьшение количества состояний автомата за счет автоматического запоминания текущей позиции в стеке

вау! а почему бы не называть это просто сопрограммами, благо что этот термин применятся аж с 60-х?

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

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

LP>>Ключевые тезисы: иерархический конечный автомат, уменьшение количества состояний автомата за счет автоматического запоминания текущей позиции в стеке

BZ>вау! а почему бы не называть это просто сопрограммами, благо что этот термин применятся аж с 60-х?

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

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

BZ>как раз это далеко не всегда можно сделать на parallel_for. погляджи на TPL/TBB — там parallel_for предлагается для простых задач, а для более слодных есть граф выполнения, вполне в стиле акторов. вот тебе пример — архиватор:

parallel_for — это был всего лишь пример. В тот же openmp или tbb входит ещё много всего на эту тему.

BZ>первый поток обходит каталоги читает входные файлы
BZ>второй поток разбивает эти данные на сжимаемые куски
BZ>пул потоков выполняют задания на сжатие
BZ>потоки из того же пула выполняют задания на шифрование
BZ>послежний поток пишет готовые блоки в архив
BZ>соответственно реализовывается всё это графом сообщений, часть задач распараллеливается в пуле потоков, часть ограничена скоростью I/O и может работать через любые асинхронные средства

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

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

LP>>>Ключевые тезисы: иерархический конечный автомат, уменьшение количества состояний автомата за счет автоматического запоминания текущей позиции в стеке

BZ>>вау! а почему бы не называть это просто сопрограммами, благо что этот термин применятся аж с 60-х?

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

так он говорит "Если мне надо реализовать конечный автомат...". а ты в ответ ему говоришь о том как реализовывать "иерархический конечный автомат" — термин который ты сам только что придумал. более того, такие сопрограммы вовсе недоступны в C#. и что ты ему докажешь? что отсутствующие в C# stackful сопрограммы нельзя реализовать автоматами

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

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

LP>>>>Ключевые тезисы: иерархический конечный автомат, уменьшение количества состояний автомата за счет автоматического запоминания текущей позиции в стеке

BZ>>>вау! а почему бы не называть это просто сопрограммами, благо что этот термин применятся аж с 60-х?

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

BZ>так он говорит "Если мне надо реализовать конечный автомат...". а ты в ответ ему говоришь о том как реализовывать "иерархический конечный автомат" — термин который ты сам только что придумал.

Никогда не слышал про иерархические конечные автоматы? А все туда же, лишь бы шашкой махать

http://www.cis.upenn.edu/~lee/06cse480/lec-HSM.pdf