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

А что такое «проверить на вызывающей стороне пришёл ли ответ или нет»?

там где ты раньше делал gen_server:call ты можешь сделать gen_server:send_request + gen_server:wait_response что будет эквивалентно, а можешь сделать: gen_server:send_request + gen_server:check_response (если нету) -> сделать что-то ещё, потом снова gen_server:check_response или gen_server:wait_response.

и всё это не городя дополнительные протоколы

Wait видимо будет блокироваться, а check нет? А в чем преимущество c send/wait по сравнению с call?

я же описал выше в чём преимущество - ты можешь сделать какую-то полезную работу, но для gen_server это выглядит как блокирующий вызов

т.е. например ты хочешь что-то протестировать. ты берёшь и meckaешь свой код, что делает gen_server:call другой функцией, что делает внутри send/wait/check

тебе не надо приводить сообщение к виду генсевера вручную. Для генсерва это между прочим {'gen' с создаваемым рефом и прочее. Тут ты просто делаешь send_request, вместо обвязывания ! оператора

Ясно, спасибо

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

да, это отрывает сразу башку если изучал erlang как ансинхронный язык процессов обменимающийся сообщениями, а потом такой берешь gen_server  а там call

а ещё можно сделать multicall очень легко

приятный юзкейс кстати

сам не пробовал, но supervisor реализует gen_server, а значит можно сделать что-то такое:

sys:suspend(MySup),
sys:replace_state(MySup, fun (OldState) -> NewState end),
sys:resume(MySup)

как так?

rpc:call(NODE, erlang, throw, [fff]).
fff

sys:suspend(MySup),
sys:replace_state(MySup, fun (OldState) -> NewState end),
sys:resume(MySup)

Это же лишь малая часть.
Я говорю о том, чтобы супервизор прошелся по всем детям и обновил у них mfa по какому-то протоколу, после чего запомнил у себя новый mfa.


Code change - я вообще не понимаю как им пользоваться, если старое описание стейта недоступно

где badrpc?

я смотрю в 23 otp уже erpc прикрутили

во какая красота с 2010 года
http://erlang.org/pipermail/erlang-questions/2010-February/049569.html

чего-то я, наверное, недопонимаю, но вот пример, берем состояние супервизора:

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 и проходимся по всему дереву.