_>>Чисто развеять сомнения — сорцы нитры открыты, можешь дать ссылку на хотя-бы аналогичный? I>Ты сказал, тебе аргументировать. Т.е. предполагается, что пруф у тебя должен быть. I>Вот как выложишь пруф, я поделюсь своими аргументами, за сказаное мной.
Кто сказал? Что сказал? Я вроде спросил. Сомневаюсь в том что есть ещё один генератор парсеров, способный подключать расширения к уже скомилированному парсеру, восстанавливаться после ошибок и при этом чтоб быстро работал. Прошу у тебя ссылку на что-то подобное. Если ничего подобного нет, то твой стёб не уместен.
Здравствуйте, so5team, Вы писали:
S>Если недостаточно, то вот, например, презентация, ссылочку на которую подкинули сегодня с утра: Kafka and Storm — event processing in realtime.
S>Чем Erlang будет лучше Java или Scala, например, в таких задачах?
Самое очевидное:
1) Erlang — DSL для создания описанной архитектуры.
2) Дистрибутивность из коробки.
3) Язык лучше подходит для обработки событий (pm; туплы; меньше ерунды типа (Tweet)tuple.getValueByField("tweet") и т.п.), и динамическая типизация весьма кстати именно для таких задач.
S>Покажите на Erlang-е что-нибудь отличное от "ура мы создали миллион легковесных процессов"
Что именно показать? Задайте конкретный вопрос.
S>"у нас все надежно, если ничего не ломается и все настроено правильно, а если что-то не настроено или таки сломалось, то 100% гарантий надежности и не бывает"...
По смыслу, не дословно:
neFormal писал, что гарантией надежности является дистрибутивность.
Я писал (отвечая на соответствующую претензию, что вм крашится при oom), что oom (не из-за утечек в нативном коде) при желании легко предотвратить с помощью system_monitor.
Mamut писал про дерево супервизоров и другие принципы OTP, способствующие написанию fault-tolerant приложений.
Вы же пока ограничились неверными или спорными утверждениями о работе Erlang VM, трюизмами в духе "100% надежности не бывает", "Эрланг хорош не для всех задач" и "на C++ можно все что угодно написать", попытками запустить 100000 нитей ОС с неизвестной целью и передергами сродни отквоченному выше, на что я сейчас и отвечаю той же монетой.
Здравствуйте, Mamut, Вы писали:
M>Блин. Почему в этом топике никто не способен: M>- прочитать про Эрланг больше, чем «аааа миллион процессов, корутины умеют так же» M>- Продолжить мылсь дальше, чем «аааа он сказал мьютексы у меня нет мьютексов»
Если тебе есть чего сказать, то говори. Намекать, многозначительно повторять "прочитай" и тд и тд не нужно.
M>В общем, почему то в этом топике все опираются строго на одну строчку строчку того, что написано.
В этом топике конкретно ты избегаешь дать внятное пояснение. Не можешь — так и пиши.
M>На практике этих библиотек нет. Те, что есть, реализуют лишь часть из доступного функционала, часто с огромными ограничениями. Ну нет в С++ возможности создать 100500 процессов без того, чтобы не убить ОСь.
S>Ок, без проблем. Какая из распространённых ОС позволит запустить одновременно 100К нитей? Какое железо ей для этого потребуется?
S>25-30 лет назад понятие "множество" означало "примерно 100".
Здравствуйте, meadow_meal, Вы писали:
S>>Если недостаточно, то вот, например, презентация, ссылочку на которую подкинули сегодня с утра: Kafka and Storm — event processing in realtime.
S>>Чем Erlang будет лучше Java или Scala, например, в таких задачах?
_>Самое очевидное:
Для кого очевидное? Для вас?
_>1) Erlang — DSL для создания описанной архитектуры.
Зачем?
_>2) Дистрибутивность из коробки.
Там уже есть дистрибутивность, обеспеченная возможностями Kafka, Storm и пр.
_>3) Язык лучше подходит для обработки событий (pm; туплы; меньше ерунды типа (Tweet)tuple.getValueByField("tweet") и т.п.), и динамическая типизация весьма кстати именно для таких задач.
Динамическая типизация на задачах обработки больших объемов данных? Повеселили. Только поставили новый вопрос: стоит ли после этого воспринимать ваши доводы хоть сколько нибудь всерьез?
И таки да, замените Java на Scala и получите pm, туплы, меньше ерунды типа... и никакой динамической типизации. Т.е. намного более высокую скорость исполнения.
S>>Покажите на Erlang-е что-нибудь отличное от "ура мы создали миллион легковесных процессов"
_>Что именно показать? Задайте конкретный вопрос.
Что-нибудь отличное от "ура мы создали миллион легковесных процессов".
S>>"у нас все надежно, если ничего не ломается и все настроено правильно, а если что-то не настроено или таки сломалось, то 100% гарантий надежности и не бывает"...
_>neFormal писал, что гарантией надежности является дистрибутивность.
Не писал. Дословно он написал следующий перл:
2. отказоустойчивость в случае ошибок (система не должна зависать и падать в принципе)
Распределенность он попытался приплести после того, как ему показали, что Erlang VM не способна обеспечить собственную надежность в условиях простой нехватки памяти. При этом он забыл про две простые вещи:
— горячий (как и холодный резерв) и миграция в случае сбоев появились задолго до того, как Джо Армстронг занялся программированием;
— одинаковые системы, работающие в горячем резерве, могут падать по одним и тем же причинам одна за одной.
Но если вы считаете, что neFormal был прав в своем утверждении, то объясните, как распределенность может обеспечить требование "система не должна зависать и падать в принципе". Особенно ту часть, которая "в принципе".
_>Я писал (отвечая на соответствующую претензию, что вм крашится при oom), что oom (не из-за утечек в нативном коде) при желании легко предотвратить с помощью system_monitor.
"при желании легко предотвратить"...
Чем это отличается от "а если что-то не настроено или таки сломалось, то"?
_>Mamut писал про дерево супервизоров и другие принципы OTP, способствующие написанию fault-tolerant приложений.
Это уже давно присутствует в других разработках и только упертые Erlang-еры, не желающие походить по представленным ссылкам, не хотят это замечать. В том же CAF дерево супервизоров один-в-один слизано из Erlang-а.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, meadow_meal, Вы писали:
_>>"Эрланг хорош не для всех задач" EP>Он в том числе "хорош не для всех задач" связанных с многоядерностью и параллельностью.
Безусловно!
_>>и "на C++ можно все что угодно написать" EP>Это было в ответ на заявления о невозможности
Подмножество задач, на которых Эрланг проявляет свои лучшие качества, безусловно можно решать на С++. Я считаю, что решение на Эрланге будет менее требовательно к квалификации программистов (т.к. Эрланг проще, чем С++, и предоставляет меньше шансов совершить фатальные ошибки), и при прочих равных чаще всего будет выполнено в более короткие сроки (хотя бы потому, что более высокоуровневый и специфичный язык позволяет более кратко формулировать решения характерных для данного класса задач проблем). Я считаю, что существует проекты с начальными условиями, делающими их успешное завершение на Эрланге возможным, а на С++ — практически нет.
(Однако это все больше напоминает тему о том, практично для писать на С++ сайты. Ведь С++ быстрый, и на нем все можно написать. Ну да, быстрый, ну да, можно.)
_>>попытками запустить 100000 нитей ОС с неизвестной целью
EP>Как это с неизвестной?
Цель неизвестна, т.к. за этим последовало слишком много "но", и в итоге здравый смысл победил (что не нужно на С++ повторять модель Эрланга, и что "Мной нигде не утверждалось, что шедулеры традиционных ОС так же хорошо справляются с сотнями тысяч потоков, как VM Erlang-а."). Он мог и без боя победить.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
I>>Догадываюсь, откуда твоя боль. "однопоточная VM" — это ты скорее всего про Node.js. Ты наверное попутал Node.js с абстрактным джаваскриптом. I>>Node.js как VM никогда, ни разу не был однопоточной VM. И это несмотря на то, что js в ноде однопоточный. Парадокс ? Как то так
V>Тем не менее, Node.js сугубо однопоточный, ы-ы-ы. )) V>Каждый "другой" поток — это отдельная несообщающаяся с другими потоками вселенная.
Наверняка общаются через очереди, типа IOCP что-нибудь. Хотя не уверен...
Здравствуйте, meadow_meal, Вы писали:
_>>>попытками запустить 100000 нитей ОС с неизвестной целью
EP>>Как это с неизвестной?
_>Цель неизвестна, т.к. за этим последовало слишком много "но", и в итоге здравый смысл победил (что не нужно на С++ повторять модель Эрланга, и что "Мной нигде не утверждалось, что шедулеры традиционных ОС так же хорошо справляются с сотнями тысяч потоков, как VM Erlang-а."). Он мог и без боя победить.
Во-первых, про цель запуска 100000. Это была наглядная демонстрация возможностей современных 64-битовых ОС. Т.к., оказалось, что многие еще мыслят категориями 20-летней давности, когда количество нитей, разрешенных к созданию в каких-нибудь OS/2 или Win NT 3.5 было ограниченно жестким лимитом. Нынче 100K нитей можно создать даже на Win8 Home, и на совсем не ТОП-овом железе.
Mamut-у я провожу простую мысль. Хоть и приходится ее формулировать по-разному:
Начинать нужно с того, что подход Erlang-а к решению проблем concurrent computing не единственный возможный. Т.е. если выделять отдельный процесс под выполнение какой-то активности от начала и до конца, то здесь Erlang вне конкуренции за счет того, что у него собственный шедулер и сборщик мусора, успешно поддерживающие работу сотен тысяч легких процессов.
Существует и другой подход, который принято называть SEDA-way, при котором отдельный процесс/нить заводится не под всю активность, а под определенную операцию (stage) в рамках активности. Сами же активности могут оформляться либо в виде легковесных короутин, либо в виде еще более легковесных объектов (конечных автоматов). Задача этих объектов всего лишь передача сообщений между stages.
или
Но суть в другом: не нужно работать с потоками ОС так же, как с легковесными процессами Erlang-а. Соответственно, повторю в очередной раз: в большинстве распространенных языков нет того, что есть в Erlang. По определению. Тем не менее, задачи из области parallel-, concurrent- и distributed computing на этих языках решаются ничуть не хуже, чем на Erlang-е.
Тем не менее, эвангелисты Erlang-а упорно продолжают твердить, что если в каком-то другом языке/платформе нет всех фишек Erlang-а, то Erlang круг по определению. На что остается только в очередной раз повторить: да, в поддержке фич Erlang-а у Erlang-а нет серьезных конкурентов. Это так, и с этим глупо спорить. Не менее глупо спорить и с тем, что для многих задач и для многих разработчиков эти хваленые фичи Erlang-а не нужны чуть меньше, чем совсем. Благодаря чему и без Erlang-а строятся и эксплуатируются системы разных масштабов, важности и сложности. До масштабов некоторых из них Erlang-у, возможно, никогда и не добраться.
Что вовсе не означает, что Erlang плох и что нужно его всячески игнорировать. Как и любой успешный инструмент, он имеет свое место, свои достоинства и недостатки. Хотелось бы, чтобы это понимали и Erlang-евангелисты.
Здравствуйте, so5team, Вы писали:
S>>>Чем Erlang будет лучше Java или Scala, например, в таких задачах? _>>1) Erlang — DSL для создания описанной архитектуры. S>Зачем? _>>2) Дистрибутивность из коробки. S>Там уже есть дистрибутивность, обеспеченная возможностями Kafka, Storm и пр.
Пожалуйста, шаг назад. Какую задачу решаем? Kafka и Storm — данность? Вы выставили на соревнование готовое решение, а затем говорите, что у вас уже все есть.
S>Динамическая типизация на задачах обработки больших объемов данных?
А что толку от статической с таким кодом? (Tweet)tuple.getValueByField("tweet")
S>И таки да, замените Java на Scala и получите pm, туплы, меньше ерунды типа... и никакой динамической типизации. Т.е. намного более высокую скорость исполнения.
Нет проблем. Но я смотрел на презентацию и приведенный там код.
Скорость бывает достаточная и недостаточная. Ресурсы бывают дорогие и дешевые.
S>Что-нибудь отличное от "ура мы создали миллион легковесных процессов".
Я не понимаю, о чем вы спрашиваете. Хотите узнать о проектах написанных на Эрланге — загляните в википедию. Спросили о личном опыте — я отвечал. Спрашивали о принципах в основе Эрланга — Mamut приводил, и к тезисам Армстронга ссылался. Личное знакомство у вас с Эрлангом тоже есть. В чем вопрос-то?
S>Но если вы считаете, что neFormal был прав в своем утверждении, то объясните, как распределенность может обеспечить требование "система не должна зависать и падать в принципе". Особенно ту часть, которая "в принципе".
Я не согласен с формулировкой, но согласен по сути. Обсуждать "в принципе" смысла нет, можно обсуждать SLA.
S>"при желании легко предотвратить"... S>Чем это отличается от "а если что-то не настроено или таки сломалось, то"?
Это ваш выбор как программиста, хотите вы чтобы у вас вся vm падала или отдельный процесс, что для вас правильнее. Я не понимаю претензий.
Я, пожалуй, закончу на этом со спором "Erlang vs другие". В приведенных претензиях к Эрлангу было несколько фактических ошибок и неточностей — сугубо практического свойства — которые мне хотелось поправить, а в итоге влез в какой-то странный спор о том лучше ли Эрланг всех на свете или нет. Нет, конечно, не лучше. По соответствующим тезисам я согласен.
Здравствуйте, meadow_meal, Вы писали:
_>(хотя бы потому, что более высокоуровневый и специфичный язык позволяет более кратко формулировать решения характерных для данного класса задач проблем).
Что конкретно имеется в виду (оставив за скобками динамику)? Тут ведь речь про сам язык, а не платформу?
_>что не нужно на С++ повторять модель Эрланга
А почему бы не повторить там где это уместно? Erlang же не идеален, даже в рамках задач которые хорошо решаются на нём. Например та же динамика — насколько она там нужна?
На C++ можно получить более легковесный по памяти вариант, и более быстрый по скорости. Например на stackless coroutine можно запустить хоть миллиард "процессов".
Здравствуйте, Sharov, Вы писали:
V>>Тем не менее, Node.js сугубо однопоточный, ы-ы-ы. )) V>>Каждый "другой" поток — это отдельная несообщающаяся с другими потоками вселенная.
S>Наверняка общаются через очереди, типа IOCP что-нибудь. Хотя не уверен...
Отдельные процессы нода могут общаться между собой, это все делается разумеется, руками. В этом нет ничего военного, но основной профит Нода совсем не в этом.
Здравствуйте, meadow_meal, Вы писали:
_>Пожалуйста, шаг назад. Какую задачу решаем?
Обработка потока данных. Конкретно в презентации приводился пример с потоком твитов. Но это не суть важно.
_>Kafka и Storm — данность? Вы выставили на соревнование готовое решение, а затем говорите, что у вас уже все есть.
Да, в этом и суть. Люди столкнулись с конкретной задачей. Они решили ее на привычных языках с привлечением готовых инструментов. Что является очередным примером того, что задачи из области parallel- и distributed computing совершенно спокойно решаются и без Erlang-а. Отсюда и вопрос: конкретно вот в такой задаче чем был бы более выгоден Erlang?
S>>Динамическая типизация на задачах обработки больших объемов данных?
_>А что толку от статической с таким кодом? (Tweet)tuple.getValueByField("tweet")
После выполнения этой строки не нужно делать никаких дополнительных проверок при работе с экземпляром Tweet.
_>Я не понимаю, о чем вы спрашиваете.
Я тоже не понимаю, что Mamut спрашивает. Но, если Erlang-ерам можно задавать такие вопросы, то почему нельзя выдать такой же вопрос навстречу?
_>Это ваш выбор как программиста, хотите вы чтобы у вас вся vm падала или отдельный процесс, что для вас правильнее. Я не понимаю претензий.
Суть вот в чем. Есть "уровень надежности", который обеспечивается "из коробки", без вмешательства программиста.
Например, у managed-языках нельзя просто так выйти за пределы массива, если не привлекать явным образом unsafe. А в C++ -- можно. Что дает возможность считать, что программы на managed-языках в плане работы с памятью более надежные, чем программы на C++. Хотя для C++ есть, например, статические анализаторы. Да и сама программа может быть сгенерирована из формального описания и не содержать проблем с выходом за пределы массива в принципе.
Вот и ситуация с падением vm при недостатке памяти их той же оперы. По умолчанию, если разработчик не предпринимает никаких мер защиты и контроля, упадет вся VM со всеми работающими в ней процессами. Даже если утечку памяти вызвал pure-Erlang-код, без участия нативных NIF-ов/драйверов.
Лично на мой взгляд, при таком поведении говорить о надежности Erlang-а нужно со значительной оглядкой. Но это мое личное мнение.
Здравствуйте, Sharov, Вы писали:
I>>На IO нужен целый тредпул.
S>Почему одного потока будет недостаточно?
Нод испльзует libio унутре. Один поток даст слишком большие задержки при большом количестве параллельных запросов.
Дело в том, что IO не вызывает JS сразу, как только получит его. Запрос проходит довольно большой препроцессинг прежде чем попадёт в JS.
Здравствуйте, Ikemefula, Вы писали:
I>В ноде вообще нет потоков и при этом VM многопоточная. Так понятно ?
Понятно, что кое-у кого каша в голове. Курить таймеры и события.
I>>>"вершиной мысли в большинстве языков" — смешно. Джава, дотнет, питон уже давно отказались от этой вершины мысли. С, С++ — вобщем, в процессе. V>>Да лан, Node.js — это дестад для детсада. "Быстро слепить и впарить". I>node.js это не слепить, это очень узкая ниша, где не требуется никаких числодробилок, а требуется в основном ввод-вывод, что естественно ведет к асинхронщине.
А почему не Эрланг, хотя бы?
I>И кстати, пока не забыл, ты так и показал образец асинхронщины "любой студент за пару часов", уже два года несёшь.
Показал многократно. Найдешь то обсуждение, найдешь весь необходимый код.
I>В дотнете асинхронный IO тормозит, дорогой слишком, а детский сад почему то node.js
Ну, дык, каков вопрос, таков ответ:
Джава, дотнет, питон уже давно отказались от этой вершины мысли. С, С++ — вобщем, в процессе.
Чего ты за этот Node.js вцепился, не пора ли оглянуться по сторонам? ))
Конечно, Node.js — это детсад.
Конечно, дотнет это не детсад, но именно библиотека Task безбожно тормозит в сравнении с идентичными по архитектуре библиотеками TBB/PPL.
I>Зато мнения по этой асинхронщине, хоть отбавляй, и что характерно — всегда без жостких данных.
Ну как это БЕЗ жестких данных, если я рядом же в обсуждении дал затраты порядка 2-3 uSec задержек с картеек onload в юзер-мод драйверах?
Или мне надо было пояснить, что численно это 2..3 * 10-6sec? Или что? ))
Поэтому, задержи кода-обработчика должны быть в этих же пределах, что получается достичь в нейтиве (порядка 0.5us на реакцию и порядка 0.05us на постановку в очередь). В дотнете НЕ получается достичь задержек менее 20uS на полный круг, то бишь разница в затратах на асинхронщине в дотнете в сравнении с нейтивом — около порядка.
Куда уж жестче-то? ))
Взял бы да замерил сам как-нить задержки дотнетного асинхронного IO.
Здравствуйте, Sharov, Вы писали:
V>>Тем не менее, Node.js сугубо однопоточный, ы-ы-ы. )) V>>Каждый "другой" поток — это отдельная несообщающаяся с другими потоками вселенная.
S>Наверняка общаются через очереди, типа IOCP что-нибудь.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Нет, корутины ортогональны future — их можно использовать вместе, но совсем необязательно. В коде Boost.Coroutine "future" вообще нигде нет.
Я имел ввиду stateless корутины из proposal для С++17.
Если же речь об обычных лямбдах, то они вполне копируемы. И нет никаких ограничений на выполнение этих лямбд как statefull-корутин.
EP>Конечно, и даже готов показать как это именно возможно на примере stackless coroutine из Boost.Asio.
Еще раз, ты скопируешь состояние корутины/лямбды, но она пришла в это состояние по событиям из внешнего мира. Как ты скопируешь внешний мир?
Т.е. какова семантика происходящего при этом и для чего это всё?
EP>future тут вообще не причём, stackless coroutine как фича языка должна брать код/функцию обычного вида и трансформировать её в класс-автомат, где поля это переменные из тела функции, а состояния — точки останова yield. В C# yield именно таким образом и реализован.
Если брать C#, то там для аналогичного служит async/await, где async является аналогом resumable из proposal для C++17. В обоих случаях сигнатуры async/resumable возвращают идентичный по назначению объект — Task/future.
EP>future и подобное появляются только в частных случаях корутин применения типа await.
Дык, именно для await это всё, для этой самой точки автоматической передачи управления следующей задаче из очереди задач текущего потока. Даже в примерах к stackless корутинам из Boost.Asio показано, что управление передаётся ручками через yield, где аргументом yield обычно служит некая блокирующая операция (т.е. операция, которая выполняется "где-то еще", но текущий поток должен быть блокирован на Task/future Wait/wait для ожидания окончания этой операции).
V>>Сейчас proposal оперирует универсальной парадигмой resumable, где resumable ф-ии могут состоять из других resumable ф-ий. EP>Насколько я помню, там был далеко не единственный proposal (причём от разных авторов). В каком оно сейчас состоянии — не знаю, надо будет проверить.
Насчет resumable — один, уже довольно-таки устаканенный. Не удивлюсь, если GCC и MSVC реализуют его ДО 17-го года (как было с future, thread и т.д., когда GCC и MSVC выкатили свои реализации более чем за год до принятия С++11).
Здравствуйте, vdimas, Вы писали:
I>>В ноде вообще нет потоков и при этом VM многопоточная. Так понятно ?
V>Понятно, что кое-у кого каша в голове. Курить таймеры и события.
Да, и снова основной и единственный аргумент с кашей и куревом
"Курить таймеры и события." — как показали события двухгодичной давности, тебе здесь курить отсюда и до луны
V>>>Да лан, Node.js — это дестад для детсада. "Быстро слепить и впарить". I>>node.js это не слепить, это очень узкая ниша, где не требуется никаких числодробилок, а требуется в основном ввод-вывод, что естественно ведет к асинхронщине.
V>А почему не Эрланг, хотя бы?
Технически, в вебе эрланг может заменить нод примерно в 100% случаев
I>>И кстати, пока не забыл, ты так и показал образец асинхронщины "любой студент за пару часов", уже два года несёшь. V>Показал многократно. Найдешь то обсуждение, найдешь весь необходимый код.
Это мягко говоря, враньё.
I>>В дотнете асинхронный IO тормозит, дорогой слишком, а детский сад почему то node.js
V>Чего ты за этот Node.js вцепился, не пора ли оглянуться по сторонам? )) V>Конечно, Node.js — это детсад. V>Конечно, дотнет это не детсад, но именно библиотека Task безбожно тормозит в сравнении с идентичными по архитектуре библиотеками TBB/PPL.
Это слабая отмазка. Ты рассказывал про нод, а проблемы с асинхронщиной оказались в дотнете.
I>>Зато мнения по этой асинхронщине, хоть отбавляй, и что характерно — всегда без жостких данных.
V>Ну как это БЕЗ жестких данных, если я рядом же в обсуждении дал затраты порядка 2-3 uSec задержек с картеек onload в юзер-мод драйверах?
Смешно. Асинхронщина в дотнете гораздо тормознее.
V>Или мне надо было пояснить, что численно это 2..3 * 10-6sec? Или что? ))
Форум пока что не показывает "рядом". А поскольку ты слишком редко делишься данными, а когда делишься, они слишком часто неверные, то смысла искать обычно нет.
V>Взял бы да замерил сам как-нить задержки дотнетного асинхронного IO.
Меня забавляет, что дотнет у тебя выступил аргументом против нода.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, meadow_meal, Вы писали:
_>>(хотя бы потому, что более высокоуровневый и специфичный язык позволяет более кратко формулировать решения характерных для данного класса задач проблем).
EP>Что конкретно имеется в виду (оставив за скобками динамику)? Тут ведь речь про сам язык, а не платформу?
Когда мы говорим об эрланге как dsl для написания конкуррентных и распределенных приложений, нет смысла разделять язык, библиотеку и платформу, так как эта троица определяет наш алфавит.
Я могу послать сообщение другому процессу не беспокоясь (до определенного предела) о том, находимся ли мы на одной ноде или разных. Или же я описываю архитектуру в терминах супервизоров и рабочих. Для реализации супервизора мне нужны линки или мониторы. Несмотря на то что посылка сообщения — операция, встроенная в язык, супервизор — понятие, привносимое библиотекой, а линки и мониторы привносятся платформой, при решении задачи они равноправные символы моего языка.
(Как язык программирования общего назначения, Эрланг далек от идеала)
_>>что не нужно на С++ повторять модель Эрланга
EP>А почему бы не повторить там где это уместно? Erlang же не идеален, даже в рамках задач которые хорошо решаются на нём. Например та же динамика — насколько она там нужна?
Не то чтобы нужна, но сильно упрощает hot code swapping (а это огромное счастье, и не только в поддержке, но и в разработке).
Ну и я не понимаю недоверия перед динамикой, ошибки типизации редки и большая часть их отлавливается диалайзером, ну а скорость — бывает достаточной.
EP>Например на stackless coroutine можно запустить хоть миллиард "процессов".
Наверное можно, но это же не повторение Эрланга. У процессов Эрланга изолированная память (для начала).
Здравствуйте, vdimas, Вы писали:
V>>>Э, нет. Эта корутина, по-сути, наследник shared_state у целевого future, представляющего собой состояние корутины. Т.е. этот shared_state заведомо необходимо делить м/у потоками. EP>>Нет, корутины ортогональны future — их можно использовать вместе, но совсем необязательно. В коде Boost.Coroutine "future" вообще нигде нет. V>Я имел ввиду stateless корутины из proposal для С++17.
Stackless корутины могут быть не такими.
EP>>Конечно, и даже готов показать как это именно возможно на примере stackless coroutine из Boost.Asio. V>Еще раз, ты скопируешь состояние корутины/лямбды, но она пришла в это состояние по событиям из внешнего мира. Как ты скопируешь внешний мир?
А зачем копировать внешний мир?
V>Т.е. какова семантика происходящего при этом
Копируются/перемещаются все созданные поля плюс индекс текущего состояния этого конечного автомата.
V>и для чего это всё?
Например для того чтобы использовать обычные правила автоматических/stack объектов C++, а не аллоцировать кадр под корутину.
Для того чтобы можно было легко передавать её из одного места в другое.
Для того чтобы генераторы (т.е. yield value) — были ForwardIterator а не single pass InputIterator.
Для того чтобы можно было такую корутину сериализовать по сети.
EP>>future тут вообще не причём, stackless coroutine как фича языка должна брать код/функцию обычного вида и трансформировать её в класс-автомат, где поля это переменные из тела функции, а состояния — точки останова yield. В C# yield именно таким образом и реализован. V>Если брать C#, то там для аналогичного служит async/await, где async является аналогом resumable из proposal для C++17. В обоих случаях сигнатуры async/resumable возвращают идентичный по назначению объект — Task/future.
Сигнатура тут тоже не причём.
EP>>future и подобное появляются только в частных случаях корутин применения типа await. V>Дык, именно для await это всё, для этой самой точки автоматической передачи управления следующей задаче из очереди задач текущего потока.
Для этого в том числе. НО, это также достигается другими, лучшими методами.
V>Даже в примерах к stackless корутинам из Boost.Asio показано, что управление передаётся ручками через yield, где аргументом yield обычно служит некая блокирующая операция (т.е. операция, которая выполняется "где-то еще", но текущий поток должен быть блокирован на Task/future Wait/wait для ожидания окончания этой операции).
Вот как раз в stackless корутинах из Boost.Asio и показано как это может быть реализовано по другому — там не нужно вызывать аллокатор для корутины, это просто класс, объект которого можно создать любым из возможных способов, его можно скопировать, перемещать, сериализовать и т.п.
V>>>Сейчас proposal оперирует универсальной парадигмой resumable, где resumable ф-ии могут состоять из других resumable ф-ий. EP>>Насколько я помню, там был далеко не единственный proposal (причём от разных авторов). В каком оно сейчас состоянии — не знаю, надо будет проверить. V>Насчет resumable — один, уже довольно-таки устаканенный. Не удивлюсь, если GCC и MSVC реализуют его ДО 17-го года (как было с future, thread и т.д., когда GCC и MSVC выкатили свои реализации более чем за год до принятия С++11).
Мне тут скинули ссылки, оказывается автор Boost.Asio сделал другой proposal N4244 — он как раз основан на дизайне stackless coroutine из Boost.Asio.
Также скинули ссылку на дискуссию из std-proposals. Там как раз обсуждают различия этих предложений, и поднимают все аспекты упомянутые мной — аллокация корутин, копирование/перемещение, сериализация, multi-pass generators. Т.е. это не выдуманные мной проблемы, они реально есть, и они заботят не только меня.
Я надеюсь что proposal от Microsoft не пройдёт, а пройдёт от автора Boost.Asio (хотя там тоже есть некоторые моменты, и над ними тоже нужно работать, но они менее значительные).
