Поучаствую, как ерлангист)
Горячая замена в Ерланг выставляется, как одна из основных фич языка. Но на практике её очень редко используют. Из всего русскоязычного сообщества вроде бы пара человек. Один точно из телефонии и там это реально нужно. Но это и не просто. Более популярна тема обычным перезапуском, как и везде. Ну или, если нужно, чтобы без прекращения работы, то это какой-нибудь кластер, и в нем последовательно обновляются ноды.
geniepro писал(а):
В принципе, в Эрланге есть модули, и при этом есть горячая замена кода на уровне функций. Если на момент замены функции она ещё кем-то вызвана и выполняется, то так и остаётся в памяти, а новые вызовы адресуются уже к обновлённой версии функции...
Да, приложение состоит из модулей. Но новый модуль просто так, самостоятельно не будет загружен с диска, если он был обновлен. Можно это задать в приложении или сделать это руками - загрузить более новый код модуля в виртуальную машину, тогда в памяти будет две версии модуля. Чтобы работающий код перешел на обновленный модуль, в ерланге есть один момент - нужно указывать имя функции полностью, вместе с модулем. Как правило, внутри модуля если функция вызывает саму себя, или другие, то полностью не пишут модуль:фунция(параметры), поэтому и обновление не сработает. В Elixir (который поверх ерланга) это работает всегда.
geniepro писал(а):
Ну. в Эрланге попроще чем в Обероне, так как нет глобального состояния...
Состояние то все равно есть. Если это цикл через функцию, вызывающую саму себя, то состояние - это входные параметры. По сути дела, входные параметры(как состояние) перейдут к следующей итерации вызова функции, но уже обновленной. Вот вам и легкое обновление. Но это только на данном уровне. Но приложения работают не совсем так.
geniepro писал(а):
Comdiv писал(а):
Нет глобального состояния, доступного по имени, или нет вообще?
http://fprog.ru/2010/issue6/practice-fp-6-ebook.pdfЦитата:
По сути, в Erlang нет привычных глобальных переменных, а есть process dictionary и настройки приложения. Первое сами создатели Erlang называют злом, которое следует использовать только в очень редких случаях, по необходимости, а второе используется в основном при инициализации приложения, но не при его работе.
Словарь процесса - по книгам это зло. В реальности же в ерланг в проде требуется разное, и бывают очень разные решения. И словарь процесса тоже может быть использован. Мы же находимся в реальном мире, не все задачи могут быть положены в иллюзорно-сферические концепции. В отладке на бою, к примеру, есть графическая оболочка, где можно свойства процессов смотреть. И если ты в словарь процесса положишь какое-то description="а это вот у нас такой-то процесс", то это сразу видно на форме и как бы даже удобно.
geniepro писал(а):
Насколько я помню, словарь процесса -- это всё-таки локальное состояние запущенного процесса.
Верно
geniepro писал(а):
Вообще, в задачах, где требуется глобальное состояние, в эрланге используется база данных. А это ,всё-таки, не то же самое, что хаотично разбросанные по модулям глобальные переменные...
Нет. Не совсем так. Глобальными переменными в ерланге по сути являются генсерверы. ГС - это такие модули, которые запущены в виде процессов. И их внутреннее состояние является глобальной переменной. А доступ к значению этой переменной происходит через вызов методов (а вызов методов и получение результата происходит через обмен сообщениями с процессом генсервера). Такое вот объектно-ориентированное программирование)) Это вот классическое решение для ерланг. Все обращения к данным будут сериализованы через очереди сообщений процессов, которые общаются. Минус тут в том, что данные обрабатываются одним процессом. А плюсы, ради чего все это и делалось: отсутствие мутексов, дедлоков итд.
Ерланг является нишевым языком, не под все задачи. Вот там, где обслуживание идет клиенты-сервер - это норм. Но все в очередь встают. То есть, общей памяти между процессами не шарится. И следовательно, те задачи, где надо шарить стейт между задачами - получается бутылочное горлышко.
Ерланг вообще не является функциональным упоранством. Мое мнение (которое не совпадает с мнением большинства в ерланг сообществе) в том, что ерланг это не ФП, а императивный язык. Когда разработка идет на уровне ОТП, то там не пишутся рекурсивные функции и всё такое, просто идут описания вызовов методов по порядку: метод вызвал, результат получил и работаешь дальше (если надо понять почему мы тут стоим и ждем - тут уже спускаемся ниже и понимаем, что сообщение ушло, потом мы встаем на ожидание ответного сообщения, потому и выходит, что вызов синхронный). А обмен сообщениями предоставляет более понятную для человека абстракцию о том, как идет обработка данных. Например, если N процессов будут обновлять общую память, то все они залочатся мутексом, и потом будут выходить из анабиоза по мере того, как ОС с них будет снимать лочку. В ерланге запросы на обновление данных лягут в очередь, а процессы уйдут в спячку, ожидая ответ. Но тут как бы получается более понятно: вот мы направили запрос, вот ждем ответ. В каком порядке мы попросили, в том и получим ответ и проснемся. Все яснее, как бы. А под капотом оно там вполне по обычному будет происходит. Даже та критикуемая тема с "хранение стейта на стеке", да не копируется там стек на каждой итерации. Я убежден, что если данных много, они просто передаются от итерации к итерации, как указатель. И следить за ссылочной целостностью не надо, ведь прошлая итерация уже всё. Короче, под капотом оно "как у всех", а для понимания процеессов будет более чистое именно представление.
БД, кстати, тоже используется. Как раз для тех случаев, когда нужно, чтобы N процессов работали над одной и той же памятью. Используется своя ерланговая БД (в памяти ets или дисковая dets). Она написана на сях, есть разные режимы доступа. Когда нужен параллельный из разных процессов - используются мутексы. Фактически это остается под капотом, потому что БД опять же является генсервером, мы его спросили, он нам дал ответ. А то, что каждый запрос выполняется в том же процессе - это под капотом.
Так.... ну что-то я сильно тут топлю за ерланг...
В общем, по поводу обновления кода в Оберон. ИМХО всё реально. Мне кажется, был же доклад Александра Ширяева. Вроде бы у него там как раз и было про загрузку и выгрузку модулей на ходу. Это вот оно и есть. Решить надо только одну задачу - передачу стейта из одной версии модуля в другую. В ерланге это всё тоже очень не просто, потому что всё может очень сильно отличаться от версии к версии, поэтому там получается некий переходник, который переведет данные со старой структуры на новую и откатит, если ничего не вышло. В Обероне проблем меньше. Как я понял, проблема только в том, что в модуле есть глобальные переменные и их надо сохранить. Ну вот нужно по сути сделать две вещи: 1) загрузить новый модуль, 2) переложить данные в новый модуль. И все. Вот вам горячее обновление кода в Обероне. Реализоваться оно будет на уровне рантайма. Синтаксис оберона менять не потребуется.