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

[Ken Robinson]

Sorry. I meant to say a separate process for each state machine. There
would be no nested states in a process.

Ken.

On Wed, Mar 23, 2011 at 12:47 PM, Ken Robinson
<kenrobinsonster@REDACTED> wrote:
> 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
>



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