[erlang-questions] gen_statem: Join states?

[Oliver Korpilla]

Hello, Frans.

So your recommendation is to prefer handle_event state machines whenever it is foreseeable that a join state is required?

I'm sorry, I didn't understand the intent behind your example.

Thank you,
Oliver
 
 

Gesendet: Samstag, 23. Juni 2018 um 10:19 Uhr
Von: "Frans Schneider" <fchschneider@REDACTED>
An: "Oliver Korpilla" <Oliver.Korpilla@REDACTED>, erlang-questions@REDACTED
Betreff: Re: [erlang-questions] gen_statem: Join states?
I use gen_statem's complex state often for exact the situation you
describe. For example, I use this state:

-record(state, {reliability_level :: best_effort | reliable,
state1 :: idle | announcing,
state2 :: waiting | must_repair}).

Now with handle_event/4, it is very easy to handle any of these
sub-states, even with enter calls. To me, this is what makes gen_statem
so nice.
Do mind that one has to make use of generic time-outs and not state
time-outs, with complex states.

Frans


On 06/23/2018 09:07 AM, Oliver Korpilla wrote:
> Hello.
>
> In the system we're building we're using gen_statem processes to keep track of signalling scenarios, essentially series of different types of messages from various sources. For linear or branching scenarios gen_statem is well prepared. But there's one thing that seemed to be missing and that is support for joins?
>
> I recently reviewed a developer's code that implemented receiving two different messages that could arrive in any order as four state functions - receiving A first (1), then receiving B (2), then entering an end state; or receiving B first (3), then receiving A (4), then entering an end state. The code entering the end state was duplicated in both (2) and (4). What essentially was needed was a "check list" of which messages had already arrived to determine the transition into the end state.
>
> Such "check list" scenarios are quite common in our work (and can grow to be more complex) and I couldn't find a direct support for it (though I was limiting myself to state_function mode), so we're now starting a separate "join process" - a gen_server that keeps and maintain the join list - and do the decision now from a single wait state. Given how light-weight Erlang processes are this works fine.
>
> What prevented me from doing this through data maintained between calls was that I would have to partition the state into information for tracking the join and the actual information kept to process the signals. This seemed less generic and clean.
>
> I'm also aware that had I rewritten the whole state machine to handle_event functions and utilized a complex state this could have helped achieve the same. What is essentially is needed, from my POV, is a way to track information pertaining to state transitions separate from information for processing incoming events, and complex states seem to do that...?
>
> What is your preferred way of doing this? Is it possible to somehow support this at the library level? Are handle_event/complex states the way to go in such situations?
>
> Thank you and regards,
> Oliver
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>