[erlang-questions] Understanding supervisor / start_link behaviour

[Ladislav Lenart]

On 2.6.2011 11:03, Ahmed Omar wrote:
> True ({local, Name}  -> register locally, not globally, with Name) but you have to be careful if having two instances alive in the same time is acceptable or not.

My bad. By "globally accessible" I meant that the locally
registered process will be available to all processes on
the local node.


Ladislav Lenart


> Steve, let's put it this way it's better to start processes under supervisor specially if you want to benefit from standard restarting strategies, it keeps your application cleaner.
> (as a hack, your case can also be solved by a monitor in the gen_server init before starting the gen_server
>   erlang:monitor(process, my_gen_event),
>      receive
>          {'DOWN', Ref, process, Pid, Reason}->
>              ok
>      end,
> )
> But using supervisor is much cleaner and safer, and easier to design with in my opinion
> On Thu, Jun 2, 2011 at 10:23 AM, Ladislav Lenart <lenartlad@REDACTED <mailto:lenartlad@REDACTED>> wrote:
>
>     Hello.
>
>     I am by no means an expert on the topic but I would like to point out
>     that the only reason you get {already_started, ...} error is because
>     you attempt to register the helper process with {local, ...}. If it is
>     a helper, there should be no reason for it to be globally accessible.
>     And if it wasn't registered, the gen_server would be restarted without
>     issues creating new helper process. The old helper would die eventually
>     just as you expect it to.
>
>
>     Ladislav Lenart
>
>
>
>     On 2.6.2011 09:15, Steve Strong wrote:
>
>         Yeah, that makes perfect sense and would obviously solve the problem.
>
>         The reason we'd gone down this path was that we had a number of "sub" processes (the gen_event just being one example) that we felt would be "polluting" the supervisor; these sub-processes
>         were just
>         helpers of the primary gen_servers that the supervisor was controlling - using a start_link in the primary gen_servers felt like a very clean and easy way of spinning up these other processes
>         in a way
>         that (we thought) would still be resilient to failures.
>
>         The thing that bit us was that we naively thought that, due to the sub-process being linked, it would die when the parent died. Of course, it does, but its death is asynchronous to the
>         notification
>         that the supervisor receives and hence it may well still be alive (doomed, but alive) when the supervisor begins the restart cycle. Our servers don't crash that often, and when they do this race
>         condition is was rarely seen, which was reinforced our misconceptions. The only thing that does surprise me is how many times the supervisor can go round the restart loop before the doomed process
>         finally exits - we have seen it thrash round this loop about 1000 times before the supervisor itself finally fails; I guess it's just down to how things are being scheduled by the VM, and in those
>         cases we were just getting unlucky.
>
>         Sounds like best-practice within the OTP world is to have everything started via a supervisor - is that a fair comment?
>
>         Cheers,
>
>         Steve
>
>         --
>         Steve Strong, Director, id3as
>         twitter.com/srstrong <http://twitter.com/srstrong>
>
>         On Wednesday, 1 June 2011 at 23:57, Ahmed Omar wrote:
>
>             Agree with Roberto, you should put under supervisor. Regarding your case, i would guess you are trapping exit in your init in my_gen_event?
>
>             On Wed, Jun 1, 2011 at 11:15 PM, Roberto Ostinelli <roberto@REDACTED <mailto:roberto@REDACTED> <mailto:roberto@REDACTED <mailto:roberto@REDACTED>>> wrote:
>
>                 hi steve,
>
>                 your gen_event should be started by your supervisor too. in this case, since you specified a one_for_all behaviour, when gen_server crashes, gen_event will be restarted too.
>
>                 r.
>
>
>                 _______________________________________________
>                 erlang-questions mailing list
>                 erlang-questions@REDACTED <mailto:erlang-questions@REDACTED> <mailto:erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>>
>
>                 http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
>             --
>             Best Regards,
>             - Ahmed Omar
>             http://nl.linkedin.com/in/adiaa
>             Follow me on twitter
>             @spawn_think <http://twitter.com/#!/spawn_think>
>
>
>
>
>         _______________________________________________
>         erlang-questions mailing list
>         erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>         http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
>
>
> --
> Best Regards,
> - Ahmed Omar
> http://nl.linkedin.com/in/adiaa
> Follow me on twitter
> @spawn_think <http://twitter.com/#!/spawn_think>
>