Supervisor

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Supervisor

Michał Ptaszek

I have three FSM machines FSM1, FSM2 and FSM3.
FSM1 creates FSM2 (linked) and FSM3 uses FSM2 (linked).

Whenever FSM2 exit I'd like FSM1 to re-create FSM2 again, so FSM3 uses FSM2 continously.

Questions:
1 - Can I use supervisor behavior in this case ?
Are there any examples of supervisor usage to look for ?
2 - Is it easier to trap EXIT signals ?


Many thanks,
Eduardo Figoli
INSwitch Solutions





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030523/c6d68a15/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Supervisor

Martin Carlson-2
On Fri, 2003-05-23 at 03:12, Inswitch Solutions - Erlang Evaluation
wrote:
>  
> I have three FSM machines FSM1, FSM2 and FSM3.
> FSM1 creates FSM2 (linked) and FSM3 uses FSM2 (linked).

It is best to have supervisors create all of your workers. If you can
structure your processes this way go ahead and do it. It should not be a
problem if fsm2 is a long lived process.  
>  
> Whenever FSM2 exit I'd like FSM1 to re-create FSM2 again, so FSM3 uses
> FSM2 continously.

I don't know the specifics of your problem but it sounds like it would
be suited to one of two supervision strategies.

1. One supervisor with a one_for_one strategy. Start the FSMs in the
following order: FSM1, FSM2, FSM3.

2. A two tier supervision structure. Tier one with a one_for_one
strategy. First start a second supervisor next start FSM3. The second
supervisor starts, with a one_for_all strategy, FSM1 then FSM2. The
chronological order for process creation under this scheme is 1. top
level supervisor, 2. second tier supervisor, 3. FSM1, 4. FSM2, 5. FSM3.

>  
> Questions:
> 1 - Can I use supervisor behavior in this case ?
Yes
> Are there any examples of supervisor usage to look for ?
> 2 - Is it easier to trap EXIT signals ?
No


>  
> Many thanks,
> Eduardo Figoli
> INSwitch Solutions
>  
>  
>  
>  
>  
--
martin j logan <martin>



Reply | Threaded
Open this post in threaded view
|

Supervisor

Ulf Wiger-4
On 23 May 2003, martin j logan wrote:

>On Fri, 2003-05-23 at 03:12, Inswitch Solutions - Erlang Evaluation
>wrote:
>>
>> I have three FSM machines FSM1, FSM2 and FSM3.
>> FSM1 creates FSM2 (linked) and FSM3 uses FSM2 (linked).
>
>It is best to have supervisors create all of your workers. If you can
>structure your processes this way go ahead and do it. It should not be a
>problem if fsm2 is a long lived process.
>>
>> Whenever FSM2 exit I'd like FSM1 to re-create FSM2 again, so FSM3 uses
>> FSM2 continously.
>
>I don't know the specifics of your problem but it sounds like it would
>be suited to one of two supervision strategies.
>
>1. One supervisor with a one_for_one strategy. Start the FSMs in the
>following order: FSM1, FSM2, FSM3.
>
>2. A two tier supervision structure. Tier one with a one_for_one
>strategy. First start a second supervisor next start FSM3. The second
>supervisor starts, with a one_for_all strategy, FSM1 then FSM2. The
>chronological order for process creation under this scheme is 1. top
>level supervisor, 2. second tier supervisor, 3. FSM1, 4. FSM2, 5. FSM3.

3. Look into using rest_for_one. If the supervisor starts
   FSM1, FSM2, and FSM3, in that order, FSM3, but not FSM1,
   will automatically be restarted if FSM2 dies.

/Uffe
--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes



Reply | Threaded
Open this post in threaded view
|

Supervisor

Vance Shipley-2
In reply to this post by Michał Ptaszek
Eduardo,

To be clear you want to have a seperate process which implements the
supervisor behaviour and not have the FSM1 process "re-create FSM2".
This supervisor process will be linked to FSM2 and will estart it when
it terminates according to the restart strategy which you specified.

You can have the FSM1 process start the FSM2 process when and if it
finds it necessary and still use the seperate supervisor strategy.
In this case the FSM1 process would call supervisor:start_child/2
which dynamically sets up a new child which from then on will be
supervised by the supervisor process.  You can also dynamically
terminate or restart it from FSM1.

Martin and Ulf described some supervisor heirarchy stategies.  You
will want to abstract out the supervision problem from the finite
state machine logic and create the appropriate handling with some
number of supervisor behaviour processes and the appropriate child
specifications.

}  1 - Can I use supervisor behavior in this case ?

You really should.  Until you want to spend your time inventing a
better mouse trap use the well tested supervisor code.

}  2 - Is it easier to trap EXIT signals ?

Some of the more purist concurrent programmers on this list would
say yes.  Their reasoning is that you would create a process recreation
strategy which is tailored to your specific problem.  For them it is
such a simple problem that they would rather just write it than use
some generic code for it.  I would suggest though that for you (and I)
it is a more complicated problem than you want to tackle.


        -Vance


On Fri, May 23, 2003 at 10:12:35AM +0200, Eduardo Figoli wrote:
}  
}  I have three FSM machines FSM1, FSM2 and FSM3.
}  FSM1 creates FSM2 (linked) and FSM3 uses FSM2 (linked).
}  
}  Whenever FSM2 exit I'd like FSM1 to re-create FSM2 again, so FSM3 uses FSM2 continously.
}  
}  Questions:
}  1 - Can I use supervisor behavior in this case ?
}  Are there any examples of supervisor usage to look for ?
}  2 - Is it easier to trap EXIT signals ?
}  
}  
}  Many thanks,
}  Eduardo Figoli
}  INSwitch Solutions


Reply | Threaded
Open this post in threaded view
|

Supervisor

Vance Shipley-2
In reply to this post by Michał Ptaszek
}  Are there any examples of supervisor usage to look for ?

Scott Lystig Fritchie posted an example back in November:

   http://www.erlang.org/ml-archive/erlang-questions/200211/msg00258.html

        -Vance