How do I create a process that creates linked processes by itself

Questions / Help
1

A program that creates a process by name supervisor. This process should in turn create linked processes to itself. The information about the processes should be supplied in a list of tuples as
[{mod1,proc1,[]}, {mod1,proc1,[]}, — {modN,procN,[]}]. The supervisor process should have received this list into its argument. The supervisor process should trap the exit signals from any of the worker
process and re spawn it. Maintain a list of pid’s that the supervisor is currently monitoring

Thanks in advance

1 Like
2

You description really just sounds like a normal supervisor, with the exception of ‘created linked processes to itself’. I assume you really mean monitored in the usual way since I doubt you want a crashing child to shut down the supervisor.

In which case the supervisor would be something along the lines of

-module(my_sup).
-behaviour(supervisor).
-export([start_link/1]).
-export([init/1]).

start_link(ChildSpecs) ->
    supervisor:start_link({local, ?MODULE}, ?MODULE, ChildSpecs).

init(ChildSpecs) ->
  Children = [{{Mod, ProcId},
               {Mod, start_link, Args},
               permanent,
               5000,
               worker,
               [Mod]}
              || {Mod, ProcId, Args} <- ChildSpecs],
  {ok, {{one_for_one, 1000, 10}, Children}}.

You can always get a list of the children the supervisor is managing with supervisor:which_children(SupName).

1 Like
3

Yes @ChocoSanju, what you are describing (if I understand it correctly) is exactly what a standard supervisor does.

Sorry to correct you @LeonardB, but a supervisor indeed links its children, but it also traps exits. This way, if a child crashes, the supervisor will get to know it but not crash itself. This would also be achievable with monitors, yes. However, if the supervisor itself crashes, all the children should also shut down, which would not happen if it was only monitoring them. Thus, linking it is :wink:

5 Likes
4

@Maria-12648430 Yes, you are indeed correct.

3 Likes
5

Well the thing is I am new to erlang so I just started learning and there’s this pdf which has questions for solving so I can understand well, I have completed over 25 questions but still there’s around 10 of them and I can’t even understand, I know how everything works But i just don’t know how to implement in the code. and thanks @LeonardB can you please explain the code mainly the init part and what is the input I have to give.
Thanks again so much

1 Like
6

@Maria-12648430 Thanks for the explanation I can understand the question better thanks to you.

1 Like
7

https://learnyousomeerlang.com/content

1 Like
8

@LeonardB Actually I’m learning by this one, I just can’t seem to put it into code sorry

1 Like
9

You’re welcome :smile:

Reading LYSE entirely is a very good idea, yes :wink:
Specifically on the topic at hand here, supervisors, see Who Supervises The Supervisors? | Learn You Some Erlang for Great Good!.
(This chapter happens to contain one of my personal favorite quotes of all time, too: “This has been a very violent chapter so far: parents spend their time binding their children to trees, forcing them to work before brutally killing them. We wouldn’t be real sadists without actually implementing it all though.” :smile_cat:).

The modern way to specify supervisor flags and child specs is with maps (vs tuples). You should also consult the Erlang documentation.

3 Likes
10

A good place to start to understand the example Erlang -- supervisor

Look at the return type for supervisor init supervisor:init/1

You’ll see it should have a list of child_spec() ChildSpec Type

The code I posted earlier in the thread was taking your specified Args and converting those into a list of child specifications (old format from before maps). The supervisor starts those children and supervises them according to the configuration of the child specification. The restart strategy I used in the example was one_for_one see: Supervision Principles

3 Likes