Newbie Test: iserve – start-up logic

In our last two posts, March 30 and April 3, we poked into Erlang/OTP conventions, supervisor processes, and application resource files.

Yes, I know, this is supposed to be a Newbie Test. Well, it is. But the opportunity to study how iserve is set up as an Erlang/OTP application is just too good to pass up.

Newbies need to nibble down nifty knowledge at every pass.

iserve’s application resource file, iserve.app, tells us that we must poke into iserve_sup.erl to see how iserve is fired up.

As noted in our March 30 post, you can recognize iserve_sup.erl as a supervisor callback module by its name, *_sup.erl, and the -behviour(supevisor) directive near the top of the iserve_sup.erl module.

iserve_sup.erl exports two functions: start_link/0 and init/1.

Here’s start_link/0.

start_link() -/>
supervisor:start_link({local, ?MODULE}, ?MODULE, []).

supervisor:start_link/3 creates a supervisor process as part of a supervision tree and ensures that the supervisor is linked to the calling process (its supervisor).

Note that the first parameter of supervisor:start_link/3 is of the form {local,Name}.

This means that the supervisor is registered locally as Name using register/2.

register/2 expects a name, Name, and a process identity, P. It associates Name with the port or process identity P.

The second parameter is the name of the callback module, in this case, iserve_sup.erl.

The third parameter is an argument passed to init/1.

So, we fire off iserve:start_link/0. This kicks off a locally registered supervisor process with the name iserve_sup. Our new supervisor now calls init/1 to find out about restart strategy, maximum restart frequency and child processes.

In our case, init/1 starts two new child processes, a supervisors, iserve_server_sup, and a gen_server, iserve_master.

We looked at how supervisor processes are configured in our March 30 post.

Christian kindly provides source comments to help us understand the functions of these two processes:

%% The servers supervisor is for keeping individual servers,
%% adding and removing them dynamically

%% The master is for book keeping all running servers and
%% to hold information about them.

So what do we find when we poke into iserve_server_sup?

Well, my eyes are too blurry to find out. But I’ll try to get back to this when the dust settles. Promise.

Back anon.

Note to wizards: corrections/comments welcomed.