Caveats on using `:gen_fsm`/`GenFSM`

[gausby]

I like using state machines, and I like :gen_fsm and our GenFSM has become pretty good (if I say so myself), but there are still people who has some good reasons not to use :gen_fsm, and instead have the state-machine in a data structure that can be passed around in a state machine, such as Saša's FSM.

I propose that we collect the opinions on GenFSM and add a caveats section to the readme. I like projects that are honest with their shortcomings like that and outline the corner cases :)

We can perhaps use this thread to discuss and learn about the shortcomings of :gen_fsm

[pavlos]

Do you think we should use the wiki for that?

[gausby]

I think it should be a section in the in the readme, or linked to in the readme if we put it in the wiki. I tend to forget that GitHub has wiki functionality, so I only get to them if they are linked to from somewhere.

[henry-hz]

I found this discussion: https://groups.google.com/forum/m/#!topic/elixir-lang-talk/Ac3B1Dj8br0
anyway, i love erlang gen_fsm, see how it was implemented here: https://github.com/devaspot/games, and good I found it here for elixir.

[pavlos]

@henry-hz We're glad you're getting some use out of it. Is it cool if we use some of your fsm code in our examples?

[gausby]

I had a conversation with a very knowledgeable person on the subject of :gen_fsm, and first of all: He doesn't have anything against :gen_fsm as such—so providing a caveat might be a bit of an overreaction—but there are one problem with the current :gen_fsm that will get solved with :gen_statem in Erlang 19.

Let me try if I get this right.

Say we have a state machine that implement a “worker scheduler”, a process that can receive tasks, which will be processed when it is running, and has the capability to pause the processing of tasks, which gives us two states: running and paused. When in the running state it will process incoming jobs or await a pause signal, and when paused it will store the jobs in a queue and otherwise wait for the run/unpause signal.

The current OTP state machine implementation will require us to keep the messages received in the paused state around, and resubmit them to the process mailbox when the machine enter running. This should be the main hurdle, and this will be fixed in :gen_statem. Basically every state machine that handle a connection that can be temporarily broken but still has to accept messages, such as a MQTT message broker, has to roll their own paused mode when implementing using :gen_fsm.

I guess I can try to make an example of this and put it in the examples-folder, and mention the examples and what they show in the main readme for discoverability.

[henry-hz]

@pavlos I will check with our CTO about sharing the code made inside the company. @gausby I think I got it, and it can be one of the issues we found when creating an CQRS aggregator based on the gen_fsm. We would appreciate an example.