ML
16> sys:get_state(psip_tport_sup).
{state,{local,psip_tport_sup},
one_for_one,
{[udp1,udp2],
#{udp1 =>
{child,<0.673.0>,udp1,
{psip_tport,start_link,
[udp,udp1,
handler =>
{handler,test_handler,#{cf_mod => test_cf_simple_reg}},
listen_addr => <<"10.10.0.26">>,listen_port => 5063,
log_messages => false}]},
permanent,5000,worker,
[psip_tport]},
udp2 =>
{child,<0.672.0>,udp2,
{psip_tport,start_link,
[udp,udp2,
#{handler => {handler,test_handler_test,#{}},
listen_addr => <<"127.0.0.1">>,listen_port => 5069,
log_messages => false}]},
permanent,5000,worker,
[psip_tport]}}},
undefined,1,5,[],0,psip_tport_sup,[]}
ничего не мешает перебить все MFA у детей или надо еще по живым детям пройтись и им чего-то
подсунуть в состояние?
Тоже вроде бы возможно - регистрируем в каждом модуле ребенка
callback
типа change_state
,запрашиваем модуль у процесса через
sys:get_status
и проходимся по всему дереву.Если я правильно понял, ты предлагаешь воспользоваться имеющимся OTP кодом, который позволяет апгрейдить состояние процесса, невзирая на то, какие у него должны быть новые MFA
Этот подход в целом понятен, хотя очень страдает от того, что в новом коде невозможно получить старые офсеты полей в рекордах и следовательно писать код по миграции, на мой взгляд, практически нереально.
Я же говорю о том, что поменяется MFA, стартовые аргументы. Процесс должен или сказать: да, я знаю как себя привести в соответствие им, или отказаться и разрешить себя рестартнуть.
Это совершенно нормальный подход, весь реакт на этом выстрелил и офигенно выстрелил, надо сказать.