DF
start_child должен вернуть тебе pid(), но только в случае успеха всей операции ведь.
Size: a a a
2019 November 21
ŹR
start_child это call же
ŹR
все остальные будут в почтовом ящике дожидаться
DF
Ну да.
ŹR
Еще и упасть могут по таймауту
AB
ага, понял, да есть такой косяк с долгими init, согласен
DF
Но энивей, я понял так, что в данном случае init не особо долгий, там просто много условий.
AB
я помню оборачивал это так: супервизио запускает прокси процесс, который стартует всегда, а потом через процеси процесс стартует конкретный и линкуется с ним, но это какое то порно
DF
Есть два подхода в работе с длинными init: отправка init-сообщения самому себе и небольшое хирургическое вмешательство с proc_lib:init_ack().
DF
Оба подхода делают плюс-минус одно и то же.
AB
типа
start_child(Args) ->
{ok, Proxy} = supervisor:start_child(?MODULE, []), %% proxy
proxy:start_concrete(Pid, Args).
TH
Есть два подхода в работе с длинными init: отправка init-сообщения самому себе и небольшое хирургическое вмешательство с proc_lib:init_ack().
для этого просто нужно кастануть самого себя в init, и уже в handle_cast доделать, что хотел
DF
Отпускают супервизор и инициализируются перед попаданием в receive-loop.
AB
для этого просто нужно кастануть самого себя в init, и уже в handle_cast доделать, что хотел
тут проблема что процесс живет без стейта некоторое время
AB
Отпускают супервизор и инициализируются перед попаданием в receive-loop.
тут проблема что не вернуть ошибку нормально, т.к. init_ack уже сделали =)
DF
Ну или трусы или крестик какб.
V
Кто-нибудь интегрировал Concuerror в common_tests/eunit ?
DF
Можно упасть красиво.
AB
Ну или трусы или крестик какб.
с прокси процессом у меня получалось и трусы и крестик =)
DF
Нет, ты просто замаскировал трусы.