Типа, супервизор рестартит процессы чтобы сбросить стейт. Менять этот стейт, на который будет производиться сброс, опасно

В эрланге, который кичиться своей 99999999% стабильностью нет ни единого зачатка систем реконфигурации на лету.

А люди в коммьюнити всерьез на голубом глазу предлагают делать все на глобальных переменных (persistent_term) или механизме апгрейда кода.

Впрочем поддержки конфигурации в эрланге тоже нет.


Есть костыли в эликсире, лучше чем ничего.


И весь этот позор выносится на форум под индексацию.

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

если бы была статическая типизация пришлось бы специальным образом писать обобщенные функции. смена шила на мыло

хотя мыло конечно лучше (если не надо протыкать дырки)

Ты с какой-то своей картинкой споришь и ей ужасаешься.

Тебе надо посмотреть на React, чтобы понять, как можно безболезненно и опционально обрабатывать изменение инициализационных аргументов.

А ты не мог бы вкратце рассказать как там в React?

Есть объекты-функции, которые что-то делают. У них есть рантайм состояние, которое они получают в процессе своей жизни, а есть инициализационные аргументы.  Т.е. параметры конструктора.

Объекты собираются в деревья и сверху вниз спускают инициализационные аргументы, создавая лес.

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

У объектов есть протокол обработки изменения аргументов. Это нужно, чтобы дом не ломать и стейт не терять. Можно попросить вызвать коллбек при смене аргументов и пообещать остаться в цельном состоянии.  А можно не просить, тогда всё удалится, заново создастся и всё дерево переинициализируется.


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

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

Т.е. протокол реконфигурации вообще ничего не ломает, а довольно гармонично вписывается.

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

а вот позор вида «положи конфигурацию в persistent_term» — это испанский стыд. Достаточно пару месяцев пописать тесты на что-то реальное, потом посмотреть на dependency injection в Java / Angular, отладить что-нибудь веселое разок на продакшне и понять, что вот так не то что делать, так даже говорить должно быть стыдно.

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

Если обновить инициализационные аргументы в супервизоре на невалидные (тоесть при которых чайлд упадёт), это будет очень сложно отловить, потому что ты обновляешь их сейчас, а процесс может рестарнуться через несколько дней. И тут, наверное, захочется какой-то механизм сброса тех инит-аргументов, которые были установлены неправильно, на те, которые были установлены верно (то есть те, которые были установлены при старте супервизора)

Я предлагаю вот такое решение, придуманное за 15 секунд

Supervisor rest_for_all
|- GenServer ConfigurationManager
|- Supervisor one_for_all
    |- GenServer worker1
    |- GenServer worker2
    ...
    |- GenServer workerN

Каждый воркер в ините спрашивает конфигурацию у процесса ConfigurationManager. Если воркер несколько раз стартует с неправильной конфигурацией, он роняет one_for_all супервизор и тогда рестартится менеджер конфигураций

/thread

Макс я помню что у вас вроде был свой супервизор что помогает вам с такими штуками, вы не пробовали редизайнить gen_server/supervisor для поддержки реконфигурирования? Есть ли там какие-то концептуальные проблемы что не позволили запулреквестить подобные изменения в отп?

> Если обновить инициализационные аргументы в супервизоре на невалидные (тоесть при которых чайлд упадёт), это будет очень сложно отловить, потому что ты обновляешь их сейчас, а процесс может рестарнуться через несколько дней

опять же, ты что-то не так себе придумал.

Логика в том, чтобы была функция   supervisor:update_tree  после завершения которой все дети или реконфигурировались, или рестартнулись если не умеют бесшовно реконфигурится.


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

Потому что альтернатива вида «сходи к глобальному процессу» — это стыд и позор, который нельзя показывать людям из других коммьюнити, чтобы не похоронить окончательно интерес к эрлангу

ОЧЕНЬ сложный для меня код.  Ну и лимит по времени вышел на это

Были какие-то сторонние супервизоры типа Director, надо посмотреть мб они умеют

Я понимаю чего ты хочешь, и это нормально такое хотеть.

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

Всё что ты хочешь, можно сделать в какой-нибудь сторонней либе. Потому что, например, бесшовная реконфигурация в рантайме требует определённого протокола для взаимодействия с процессами (типа, послать сообщение {'$gen_reconfigure', NewInitArgs}, и получить сообщение ok).

Абсолютно нормально и уместно видеть это в супервизоре, который должен поддерживать все в целостности. Просто картина этой целостности должна уметь меняться

А предусматривает ли термин "реконфигурация" возможность частично поменять дерево процессов?

Допустим, я подключил какой-то новый протокол и мне нужно новых рабочих теперь запустить

мне один из инсайдоров нвидиа прислал вакансию программиста на камле. тут кому-нибудь это интересно? вроде кроме Валкина ещё кого-то тут видел, кто умеет.

Это к Эрмине разве что

она не может работать в офисе.