[erlang-questions] Nested finite state machines - Existing Implementations?

[Ken Robinson]

Hi Ulf,
Thanks for the reply. Much to digest. From what was said in the post
and what you've said here I think I will try a separate process for
each state with perhaps gproc as a lookup mechanism. I'll experiment
with plain_fsm and gen_fsm.

cheers,
Ken.

Looking through the
On Tue, Mar 22, 2011 at 5:50 PM, Ulf Wiger
<ulf.wiger@REDACTED> wrote:
>
> Hi Ken,
>
> I don't think nested state machines are used much in the erlang world,
> since it's generally considered detrimental to "complify" the FSM running
> in a single process.
>
> OTOH, sometimes, you need to, in order to implement some behaviour.
> One of the examples I've used in presentations was when implementing
> a Diameter stack (rfc3588). It (arbitrarily) combines different FSMs into
> a single thread, and this caused me to refactor the spec into multiple
> cooperating FSMs (using plain_fsm). The price you pay is that it becomes
> hard  to check that your code actually matches the spec - even though it
> became easier to see that the code did what I think was the intention…
>
> At AXD301 (a long, long time ago, it seems), we had the need for at least
> two levels of nesting, for a call-control FSM and a transport FSM - one for
> each call leg. We did this by making the call-control FSM an active process,
> a la plain_fsm, and implementing the transport FSMs as gen_fsm-style
> callbacks (but dispatched from within the CC FSM). We went through many
> iterations, so it's quite likely that we eventually departed from this model
> and implemented all FSMs as separate processes.
>
> And going for as many processes as the problem called for was one of the
> driving forces behind gproc, which can serve as a index for locating the FSM
> you need (based on ordered_set semantics and supporting QLC, you should
> be able to efficiently select even a subset of multiple FSMs).
>
> http://github.com/esl/gproc
>
> In my presentation, "Death by Accidental Complexity", I use a parameterised
> bare-bones event loop for FSM programming, which I also extend with a
> "select vector" to support a form of selective receive in the FSM callbacks.
>
> Most of these things, and more (e.g. a link to ExAT) can be found in the following
> thread:
>
> http://forum.trapexit.org/viewtopic.php?p=15811&sid=197b687b90d851e0b7ffdaa4f1465f8f
>
> If memory serves, Joel Reymont solved the problem to his own satisfaction in
> the poker server, but my quick late-night googling failed to reveal a good link.
>
> Joel?
>
> BR,
> Ulf W
>
>
> On 22 Mar 2011, at 04:47, Ken Robinson wrote:
>
>> Hi All,
>> I have a standard which I'm implementing which calls for nested state
>> machines which have push and pop states and entry and exit actions.
>> I'm having difficulty using gen_fsm to do this. I've been looking at
>> plain_fsm by Ulf Wiger which looks promising. Before I reinvent the
>> wheel, is there any existing fully fledged nested state machines out
>> there?
>>
>> --
>> regards,
>> Ken Robinson
>> Mob +61438681120
>> Home +61738523767
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
>
>
>
>



-- 
regards,
Ken Robinson
Mob +61438681120
Home +61738523767