[erlang-questions] Beginner gen_server and child monitoring

[Giovanni Giorgi]

Hi, 
 First of all thank you to Jesper and Troben.

On 03/ago/2016, at 14:26, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:

> 
> On Thu, Jul 28, 2016 at 7:47 AM, Giovanni Giorgi <jj@REDACTED> wrote:
> Now the question is: Is a correct approach?
> 
> The key observation is: "How do you want to handle error in the processes?"
[snip]
> You could simply run the tickers as Torben suggests and then spawn_link them under the main process. 
...
> You could also use an asymmetric solution: spawn_monitor the tickers and have the tickers monitor the main process. This allows you to handle the case where you want to restart a crashing ticker for instance, but you have to write the logic yourself.

In my first implementation I am using spawn_monitor because I want to know if some process die, but I do not want to tear down the entire tree for a stupid network error.
I am also thinking to get a stronger child process which will crash only for a very bad error (i.e. out of memory or other important logic error).
I think I need to implement a supervisor-like behavior for the server watching the small processes

> 
> In general, spawning processes without knowing where they are only works for processes which are guaranteed to terminate. Otherwise, you end up with process leaks.
I got it.

By the way I am always amaze by how the Erlang language seems like a domain language, because the use of a bunch of right atom give me the freedom to model a problem in an easy to read fashion.

> 
> The final solution is to use a supervision tree: have a main_sup with children MainProcess and TickerPool, the latter being a simple_one_for_one supervisor. Each ticker is added into the TickerPool with supervisor:start_child. It is the the most complex solution, but it has an advantage over the simpler methods: it encodes a *policy* in the supervisors for handling failure modes. That is, you can tolerate some tickers dying, but not too many before trying to restart larger parts of the system.
> 
> So the TL;DR is to think about the failure mode of the application and write it accordingly.
> 
> 
> -- 
> J.

--
Giovanni Giorgi
jj@REDACTED






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