[erlang-questions] gen_statem: Join states?

Frans Schneider fchschneider@REDACTED
Sat Jun 23 10:19:30 CEST 2018

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.


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

More information about the erlang-questions mailing list