simple_one_for_one worker

[Michael Leonhard]

Tee,

Perhaps you are confused about how to implement simple_one_for_one
supervisor and its children?  You can see a real implementation in:

http://tamale.net/erlchat/chat-0.1/src/chat_liason_sup.erl
http://tamale.net/erlchat/chat-0.1/src/chat_liason.erl

I am just a beginner with Erlang, but I will do my best to explain. 
You should make a start_link/0 method to start your supervisor.  This
method should call supervisor:start_link/3 to say "I implement the
supervisor behavior.  Please start me!":

chat_liason_sup:start_link() ->
    supervisor:start_link({local, chat_liason_sup}, chat_liason_sup, []).

What happens then is that the Erlang supervisor module makes a new
process for your supervisor to live inside and then calls your
module's init method.  The init method should return a "specification"
tuple that says what kind of supervisor it is.  In our case, it is a
simple_one_for_one supervisor, so this structure defines the module
and parameters that are used to start the children:

chat_liason_sup:init(_Args) ->
    LiasonSpec = {chat_liason, {chat_liason, start_link, []}
        , temporary, brutal_kill, worker, [chat_liason]},
    StartSpecs = {{simple_one_for_one, 0, 1}, [LiasonSpec]},
    {ok, StartSpecs}.

No children are started yet! The supervisor only prepares to manage
children.  When a child needs to be started, your program should call
the child module's start/1 method.  That start method should call the
supervisor:start_child/2 method to request a new child process:

chat_liason:start(DataForChild) ->
    supervisor:start_child(chat_liason_sup, DataForChild).

Notice that this call includes only the supervisor's name and some
data for the new child.  The child's module, start method, and basic
data have all been defined previously, when the supervisor first
started.

The supervisor:start_child/2 method sends a message to the running
supervisor process to ask for a new child.  This message is handled
automatically by the Erlang supervisor module running the process.  It
calls the child's start method like this:
chat_liason:start_link(DataForChild).

In this example, the children are all gen_servers.  The child starts
itself as a gen_server:

chat_liason:start_link(Args) ->
	Options = [],
	gen_server:start_link(chat_liason, Args, Options).

>From then on, the child process runs a loop in the Erlang gen_server
module.  The process calls methods in the child module when certain
things happen.  It calls init/1 to let the child module get ready and
make its initial state.  When a message comes in, the gen_server
module processes it and calls the child's corresponding method:
handle_call(Request, From, State) -> Result
handle_cast(Request, State) -> Result
handle_info(Info, State) -> Result
If the returned Result is {stop,Reason,NewState} then the gen_server
calls the child's terminate/2 method and then the gen_server dies.

You cannot use terminate_child/2 on a simple_one_for_one supervisor. 
A child dies when it gets a message and then returns stop in its
Result tuple.  All of the methods in your module that implement the
supervisor behavior are called automatically by the Erlang supervisor
module.  Similarly, the child's methods to support gen_server behavior
are called automatically by the Erlang gen_server module.  You should
never call these methods yourself.

The details of the supervisor and gen_server modules and behaviors can
be found in the stdlib documentation.  Click on supervisor or
gen_server in the frame on the left:
http://erlang.se/doc/doc-5.4.8/lib/stdlib-1.13.8/doc/html/index.html

I hope this helps.

-Michael Leonhard
michael206@REDACTED

On 7/1/05, tty@REDACTED <tty@REDACTED> wrote:
<snip>
> I am aware of those callback however who should call them ? Should the Supervisor
> do that after calling supervisor:terminate_child ? Or does supervisor:terminate_child
> call one of the handle_* functions.
> 
> Furthur more since my gen_server process should terminate after it is done
> processing does this imply it should call supervisor:terminate_child on itself ?
<snip>