AN
:simple_one_for_one потому что он сильно по-другому себя ведетSize: a a a
2020 January 03
D
единственное, что приходит на ум, это то что пацанам не нравится
Есть какие-то затыки, которые стоит учесть?
AN
в чем затыки? в
simple_one_for_one?D
в чем затыки? в
simple_one_for_one?Незнаю, поэтому и интересуюсь, есть ли?
МБ
Стратегия :simple_one_for_one была сделана для тех случаев, когда количество воркеров не определено и надо динамически их создавать, при этом, надо чтобы оно было просто в реализации. Пулы какие-нибудь, например. В остальных случаях я бы рекомендовал рассмотреть gen stage вместе с flow
ŹR
DynamicSupervisor сделан вместо simple_one_for_one потому, что simple_one_for_one это несусветная хрень, пытающаяся использовать api супервизора абсолютно другим способом чем все остальные стратегии
ŹR
Чтобы понять почему это хрень, представьте себе chrontab, в котором вместо известного вам синтакса используется HTML. Причём теги берутся от балды. Типа “то что в li - это значит минуты, а то что в head - это часы. Года зададим тегом b”
v
Чтобы понять почему это хрень, представьте себе chrontab, в котором вместо известного вам синтакса используется HTML. Причём теги берутся от балды. Типа “то что в li - это значит минуты, а то что в head - это часы. Года зададим тегом b”
А можно как-то по другому понять, почему это хрень?
D
Короче, суть такова, что у меня все дочерние процессы однотипны (по сути это один и тот же модуль, только запускается с разными параметрами)
D
И каждый процесс имеет «имя» (регистрируется через gproc)
D
При динамическом супервайзере - все отрабатывает корректно
D
Если пытаться запустить как обычный супервайзер - ругается на то, что такой процесс уже запущен
v
Если пытаться запустить как обычный супервайзер - ругается на то, что такой процесс уже запущен
Покажи код с обычным супервизором
D
Позже 🙂 я его стер и ушел дальше, надо в недрах репо лазить
МБ
Я такой ерундой занимался в самом начале изучения erlang именовал процессы зачем-то, потом по именам сообщения рассылал... Потом взял gproc ему ж пофиг на имена, пид и атрибуты.
А по проблеме вангую, что при запуске динамиком указывается имя модуля для запуска. А при попытке запуска обычным имя модуля указывается как имя процесса, в этом случае он нафиг пошлёт после первого процесса, всё верно.
А по проблеме вангую, что при запуске динамиком указывается имя модуля для запуска. А при попытке запуска обычным имя модуля указывается как имя процесса, в этом случае он нафиг пошлёт после первого процесса, всё верно.
2020 January 04
IK
Если пытаться запустить как обычный супервайзер - ругается на то, что такой процесс уже запущен
Тебе нужно type передать в спецификации
IK
child_spec = %{
id: Supervisor,
start: {Supervisor, :start_link, [args]},
restart: :permanent,
type: :supervisor
}D
Благодарю)
D
Я такой ерундой занимался в самом начале изучения erlang именовал процессы зачем-то, потом по именам сообщения рассылал... Потом взял gproc ему ж пофиг на имена, пид и атрибуты.
А по проблеме вангую, что при запуске динамиком указывается имя модуля для запуска. А при попытке запуска обычным имя модуля указывается как имя процесса, в этом случае он нафиг пошлёт после первого процесса, всё верно.
А по проблеме вангую, что при запуске динамиком указывается имя модуля для запуска. А при попытке запуска обычным имя модуля указывается как имя процесса, в этом случае он нафиг пошлёт после первого процесса, всё верно.
А как ты получал имя процесса из самого процесса?
D
Это вообще возможно? Теоретически, процесс может получить свой PID. Если мы знаем пид, можем ли мы из Registry выдернуть имя процесса?