AB
Я не хочу чтобы клиент заморачивайся этим, я хочу чтобы он сделал start и после этого получил либо ошибку либо готовый к работе pid
Size: a a a
2019 November 21
DF
Тогда пусть висит N времени.
AB
Ну один клиент может висеть, другое дело что остальные должны иметь возможность сделать start в это время
DF
В общем, это реализуемо.
AB
В gun такое сделано через wait_up
AB
Но там клиент и так обязан ловить сообщения от gun
AB
Да реализуемо конечно, и как обычно многими способами разной степени паршивости ;)
DF
У тебя есть три примитива: отложенный init, монитор и ресив.
DF
Не вижу паршивости совсем.
IG
Тогда я бы пользовал именно proc_lib:
init(_) ->
% something here, supervisor awaits
proc_lib:init_ack({ok, self()}),
% supervisor unblocked
% at this point you might have a message in mailbox already
% do long stuff
{ok, somestate}.
так родитель (супервизор в общем случае) получить два сообщения в свой мейл бокс, один из которых он обработает стандартно, а второй будет внезапным.
Это конечно можно игнорить, или даже за использовать, но как-то не супер очевидно
Это конечно можно игнорить, или даже за использовать, но как-то не супер очевидно
DF
С чего бы?
IG
proc_lib:init_ack({ok, self()}) - посылает сообщение родителю, что он может больше не ждать. модуль Ген сервера дергает сам эту функцию после твоего initВот и получиться, что твой процесс отправит два сообщения родителю
DF
Да, верно. Можно пользовать proc_lib:start_link.
IG
если нужно реализовтаь тоже самое что ты хотел, но без двойной отправки сообщения, нужно самому вместо
gen_server:start_link вызывать proc_loib:start_link, а там самому делать гарантированно proc_lib:init_ack, затем gen_server:enter_loopDF
Но вообще у меня не было проблем с этим ни разу.
DF
Да, верно.
IG
ну ты успел ответить себе до)
IG
вообще,
gen_server:cast(self(), init) часто делал или подобное. никаких проблем, надо просто быть способным ответить вызывающим, что ещё неготовDF
Ну есть проблема с неготовым стейтом, да.
DF
То есть придётся уметь хендлить неготовый стейт с кучей undefined.