Generic FSMs in Erlang

I've also gotten good mileage out of "gen_event"; I have a protocol with a generic connection layer, then a modular part where you claim you support "Module X", which is implemented as a gen_event plugin that first verifies you can do that, then allows this connection to have that module. It makes it really easy to write something relatively secure by ensuring you can get to certain capabilities if and only if you pass a certain check to validate you ability to have them. It's a good tradeoff between typing (as in, typing things on the keyboard) and security for me.

Thanks, I am enjoying it. I'm working on a holiday project that includes writing an Erlang server that will need a FSM. Even though I've written many FSMs in other languages I'm new to Erlang, so it's great to have this nice guide. Glad I decided to peruse Hacker News before I started on the FSM implementation!

That what was I thought when I saw the title, too. However, from experience I realized that making any sort of comment alluding that without adding substantively to the discussion would certainly elicit sanctimonious shows of disapproval.

The key to getting away with that in this topic would be to make an insightful comment about finite state machines, and throw the FSM reference in at the beginning or the end. Extra bonus if you can skillfully weave a Flying Spaghetti Monster narrative into your comment, like a parable.

"no on_entry / on_exit callbacks."

That's not too hard to fix; write your handle_event callback as something that observes the state, dispatches out to the "really_handle_event" function, observes the new state, and fires the desired callback, implemented however you want them to be. Ten reusable lines or so.

"Also, I'm not sure you can use gen_fsm sequentially by itself (i.e. without Erlang process)."

Not really much point, really. The gen_fsm itself is basically wrapping the state machine described there into a supervisor tree. If you don't want the supervisor tree, it is utterly trivial to write a state machine of your own in Erlang. It is one place where pattern matching excels. You want some sort of record indicating your state, then you can do things like:

  -record(state, {name, val1, val2}).

  event1(State=#state{name = initial}) -> handle...
  event1(State=#state{name = connecting}) -> handle...
  event1(State=#state{name = connected}) -> handle...

  event2(State=#state{name = initial}) -> handle...

and so on. A little more plumbing is necessary to manage returning the new state but that's the basic idea, which is just about the only other thing you "get" from gen_fsm "for free".

Hello all, the simplest answer for why we did not include the gen_fsm is that it is not used very often. In 11 years of Erlang programming I have only used it a handful of times. You can easily replicate it's behaviour with the gen_server in any case. Furthermore explaining it's use clearly turned out to be complicated. Rather than confuse readers, and add pages to an already lengthy book, we decided to skip it. If you clearly understand gen_server, superviser, application, and gen_event you will be able to pick up gen_fsm when you need to. If we do a second edition perhaps we can include the FSM as an appendix.

The gen_fsm implementation is elegant and I do recommend taking a look at it but you probably won't find yourself using it all too often. At the end of the day we wanted to write a book that prepared people for real world Erlang situations and the gen_fsm does not weigh heavily in those scenarios.

What's wrong with spawning a separate process for the FSM? You will still typically have it linked in your supervisor hierarchy.

> Also, I'm not sure you can use gen_fsm sequentially by itself (i.e. without Erlang process).

Why would you want to do that ever?

The authors don't care for it much :). I however argue its great for when it fits the problem. Like implementing a protocol like XMPP.