Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 28 мар 2024, 23:37

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 79 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8
Автор Сообщение
 Заголовок сообщения: Re: горячая замена кода
СообщениеДобавлено: 14 мар 2018, 11:23 
Не в сети

Сообщения: 203
budden писал(а):
create table служит вместо записей. Конечно, стоимость таблицы намного выше, чем стоимость рекорда. Однако в SBCL, где есть "просто записи" и "классы", существует не менее 5 возможных способов поменять определение структурного типа. Вам не понравится, что так много. В SQL же он один: alter table.

Я имел в виду, что если была определена структура данных и экземпляры этой структуры крутятся в системе, а затем она вдруг меняется без перезапуска всей системы -- то тут возникает проблема конвертации экземпляров из старого формата в новый. Как эта проблема решается в T-SQL и как она может быть решена в обероне?
В обероне экземпляры старой версии записи уничтожаются (ну, может быть сериализуются куда-то перед этим), старая версия модуля выгружается, загружается новая версия модуля. Это не совсем "горячая замена кода", во всяком случае, не в том виде, как в эрланге. Но в эрланге динамическая типизация, там проще в этом плане...


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: горячая замена кода
СообщениеДобавлено: 14 мар 2018, 12:33 
Не в сети

Сообщения: 350
Она по сути решается не в T-SQL, а в SQL. Просто хранимые процедуры умеют это переживать. Оберон можно рассматривать как аналог суммы из T-SQL и SQL. Как это решить в Обероне - можно решать массой разных способов, начиная от инвалидации всех существующих экземпляров и заканчивая хранением новых полей в слабых хеш-таблицах (которые для этого придётся добавить в BBCB). У каждого способа будут свои недостатки, вытекающие из объективной сложности задачи.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: горячая замена кода
СообщениеДобавлено: 14 мар 2018, 12:36 
Не в сети

Сообщения: 203
В обероне (в том числе в блекбоксе) что бы обновить изменённые сущности модуля нужно перезагрузить модуль, а это может потребовать выгрузку всех клиентов модуля. В-общем, это не совсем горячая замена кода. Это мало чем отличается от обычных dll...


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: горячая замена кода
СообщениеДобавлено: 14 мар 2018, 12:38 
Не в сети

Сообщения: 350
Я знаю. Над этим можно работать, улучшать (или ухудшать, в зависимости от религии).


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: горячая замена кода
СообщениеДобавлено: 14 мар 2018, 14:25 
Не в сети
Администратор
Аватара пользователя

Сообщения: 108
Если проектировать специально под горячую замену, то возможны кое-какие приемы с Meta.
Я так сделал в своей экспериментальной реализации сервера.
Модуль загружается для того, чтобы выполнить задание. После этого выгружается.
Код: "OBERON"
  1. Meta.Lookup("TcpTask", m);
  2. IF m.obj = Meta.modObj THEN
  3. m.Lookup("Process", p);
  4. IF p.obj = Meta.procObj THEN
  5. p.GetVal(v, ok);
  6. IF ok THEN
  7. tmp.writer.Load(v.proc(tmp.head, tmp.body));
  8. Kernel.UnloadMod(Kernel.ThisMod('TcpTask'));
  9. END
  10. END
  11. END

Для увеличения производительности возможно делать выгрузку модуля и загрузку нового, если файл с кодом модуля изменился на жестком диске.

Вот так я вижу безопасную горячую замену в ББ.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: горячая замена кода
СообщениеДобавлено: 14 мар 2018, 16:03 
Не в сети

Сообщения: 350
Угу.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: горячая замена кода
СообщениеДобавлено: 23 июл 2018, 13:13 
Не в сети

Сообщения: 3
Поучаствую, как ерлангист)
Горячая замена в Ерланг выставляется, как одна из основных фич языка. Но на практике её очень редко используют. Из всего русскоязычного сообщества вроде бы пара человек. Один точно из телефонии и там это реально нужно. Но это и не просто. Более популярна тема обычным перезапуском, как и везде. Ну или, если нужно, чтобы без прекращения работы, то это какой-нибудь кластер, и в нем последовательно обновляются ноды.

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) переложить данные в новый модуль. И все. Вот вам горячее обновление кода в Обероне. Реализоваться оно будет на уровне рантайма. Синтаксис оберона менять не потребуется.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: горячая замена кода
СообщениеДобавлено: 24 июл 2018, 10:01 
Не в сети

Сообщения: 146
Спасибо, это интересно.

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: горячая замена кода
СообщениеДобавлено: 24 июл 2018, 17:12 
Не в сети

Сообщения: 3
Comdiv писал(а):
Можете сказать, насколько это часто возникающая проблема и насколько хорошо покрывается имеющимися средствами, такими как БД.

Не часто встречается. Из за ниши, которую занимает Erlang. Чаще всего это клей: из сети забрал, в диск положил, или наоборот. Управление потоками информации. Обработка пакетов. То есть, как правило, запросы обычно изолированы друг от друга по данным.

Но система существует давно, поэтому разработаны и методы решения таких проблем. Если надо читать вот прям принципиально из одной памяти (это бывает нужно, когда нужна очень высокая скорость), то с этим отлично справляется нативная система хранения данных в памяти (ее можно назвать БД) - ETS (Erlang Term Storage). Это хранилище ключ-значение. Говорят, есть инструмент memcache, сходный по функционалу. Но тут ETS получается родной, встроенный, без накладных расходов и на базовых типах языка. Ключ по хешу, параллельный доступ из разных процессов. Если кроме чтения там будет еще и запись, то будут временные лочки мутексами (есть режимы write_concurrency, read_concurrency, итераторы, возможность залочить таблицу, чтоб никто не поменял, пока её обходишь). Как у всех. В общем, ETS - всегда используется, когда нужно экстремально высокие скорости и параллельный доступ к информации внутри системы. Пример, у кого самый дикий хайлоад - это https://erlyvideo.ru/ и его создатель Макс Лапшин. Частенько на докладах рассказывает, как это все работает под гигабитами.

Если прям надо какие-то матрицы перемножать в большом количестве, то это не про ерланг. Но это бывает нужно. В телекоме похожее бывает. С бинарниками машина справляется отлично, может разбирать, отдавать, забирать, парсить. Но если нужно что-то сложное обработать (и этого нет в стандартных библиотеках, которые и так уже нативные), то в этом случае есть три классических решения: 1) порт - это запуск внешней программы на любом ЯП и общение с ней через pipe; 2) nif - написание бинарного модуля (си, итд, мне нравится вариант на Rust), который будет встроен в ВМ ерланг и будет вызываться как обычная функция модуля в приложении 3) написание c-node, то есть нода, которая будет входить в кластер машин Erlang и общаться с ними, но сама она будет не ерланговая. Либо самому что-то придумать, типа отдать в другой сервис кусок данных по сети, получить ответ. Варианты есть, в общем.

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 79 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club