Vance Shipley vances@REDACTED
Fri May 23 20:36:41 CEST 2003


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

}  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.


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

More information about the erlang-questions mailing list