[erlang-questions] Is supervisor notified when child is restarted?

[Martin Koroudjiev]

Thank you for your time and information. Process groups sound
interesting. I will dig deeper.

Regards,
Martin

On 7/28/2015 6:24 PM, Sean Cribbs wrote:
> Woops, forgot to include the link:
>
> [1] http://erlang.org/doc/man/pg2.html
>
> On Tue, Jul 28, 2015 at 10:23 AM, Sean Cribbs <seancribbs@REDACTED
> <mailto:seancribbs@REDACTED>> wrote:
>
>     Hi Martin,
>
>     It sounds like you need either to use either registered names,
>     process groups, or the one_for_all strategy. Registered processes
>     are the easiest way, you can simply refer to them by the atom --
>     but you must expect that sometimes messages will be lost if the
>     process is restarting. Alternately, if you change this
>     supervisor's strategy to one_for_all you will ensure that every
>     process always has the correct state (assuming it already starts
>     up in the correct state), but existing work from non-failed
>     processes can be lost. For process groups, you can use pg2 [1]
>     which comes with OTP, or there are several alternate
>     implementations available on github, but messaging the other
>     processes in this small group will incur additional overhead.
>
>     Each solution has tradeoffs, I hope that helps you decide which
>     one to use.
>
>     On Tue, Jul 28, 2015 at 10:03 AM, Martin Koroudjiev
>     <mrtndimitrov@REDACTED <mailto:mrtndimitrov@REDACTED>> wrote:
>
>         Hello,
>
>         I am wondering how can I get notified when a child process is
>         restarted?
>         Imagine this simple scenario - supervisor with one_for_one
>         strategy and
>         3 gen_servers as workers. Each in its state has the PIDs of
>         the other 2
>         and sends them messages. Now if one child gets restarted, the
>         other 2
>         will have the old PID. How can I notify them?
>
>         I can't restart the whole supervision tree because the number
>         of child
>         processes is buried deep in the initialization logic of the
>         application.
>
>         Regards,
>         Martin
>         _______________________________________________
>         erlang-questions mailing list
>         erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>         http://erlang.org/mailman/listinfo/erlang-questions
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150728/ae7d0ae9/attachment.htm>