V
В целом да, можно было бы переиспользовать code_change с доп параметром или добавить update_config, но в целом надо рассматтривать различные юзкейсы апдейта конфигурации которые могут быть.
Size: a a a
2020 October 18
V
Можно вполне добавить issue и начать обсуждение как это лучше делать
ИИ
В OTP, вроде, уже несколько мест с опциональными коллбеками (первым в голову пришло format_status)
ну да, но start|init вроде не опционален? а update это тоже самое
V
ну.. добавить в supervisor update spec, который дёргает опциональный update_config, или рестартует с новыми параметрами
V
но мне кажется вполне канает просто запилить свой супервизор для начала, otp ребята довольно консервативны
ИИ
ну.. добавить в supervisor update spec, который дёргает опциональный update_config, или рестартует с новыми параметрами
Я к тому что update это тоже самое что start вроде как
V
зависит от логики внутри генсервера. Если делается отложенный инит, то не тоже самое
ИИ
но мне кажется вполне канает просто запилить свой супервизор для начала, otp ребята довольно консервативны
Ну вот да. Я бы сделал возможность update_child обновляющиц стейт супервизора для новых но без прибытия старых, а возможностью отправки им сигнала
AN
code_change в любом случае подразумевает рестарт прцесса. Похоже нужно свой механизм делать
V
эмм? как раз наоборот
V
release handling в помощь, ни о каком рестарте процесса речи не идёт
V
Вот как это работает:
• Suspend the processes using the module (to avoid that they try to handle any requests before the code replacement is completed).
• Ask them to transform the internal state format and switch to the new version of the module.
• Remove the old version.
• Resume the processes.
AN
ну да, suspend / tranform и resume это не рестарт. Не так выразился видимо... init не вызывается, значит рестарта нет
ML
Я вот наконец-то понял как мне не хватало gen_server:check_response/gen_server:send_request который завезли в otp23. Очень удобно получается для пропертибейз тестирования.
Я чет пока не вкурил в чем смысл
V
ты можешь эмулировать gen_server:call без обязательного блокирования.
ML
Вот как это работает:
• Suspend the processes using the module (to avoid that they try to handle any requests before the code replacement is completed).
• Ask them to transform the internal state format and switch to the new version of the module.
• Remove the old version.
• Resume the processes.
Да, это в принципе почти то.
ML
ты можешь эмулировать gen_server:call без обязательного блокирования.
А, это типа как руками послать запрос и потом проверить: пришел ответ или нет?
ИИ
Вот как это работает:
• Suspend the processes using the module (to avoid that they try to handle any requests before the code replacement is completed).
• Ask them to transform the internal state format and switch to the new version of the module.
• Remove the old version.
• Resume the processes.
а можно вручную инициировать вызов этого метода?
AN
Даже эта штука: https://hexdocs.pm/elixir/DynamicSupervisor.html не позволяет менять child_spec без рестарта этого child. Т.е. новые спеки только для новых процессов.Если такой вариант подходит, то можно глянуть реализацию
V
А, это типа как руками послать запрос и потом проверить: пришел ответ или нет?
да, удобно когда ты хочешь построить детерминированный автомат и проверять руками пришёл ответ или ещё нет