4 ms·

Generic FSMs in Erlang

60 points by keyist 16y ago

mononcqc 16y ago
Author, here. I hope you enjoy.
- pivo 16y ago
  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!
chunkbot 16y ago
Good stuff. Compared to the more "popular" generic behaviours like gen_server, gen_fsm doesn't get a lot of attention. It's nice to see it added to your tutorial with this level of detail.
- jerf 16y ago
  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.
nivertech 16y ago
Too bad the new "Erlang and OTP in Action" book leaves gen_fsm out of scope. Anyway gen_fsm behavior is pretty weak comparing to FSM frameworks I used in C++: no on_entry / on_exit callbacks. Also, I'm not sure you can use gen_fsm sequentially by itself (i.e. without Erlang process).
- kungfooguru 16y ago
  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.
- grogers 16y ago
  What's wrong with spawning a separate process for the FSM? You will still typically have it linked in your supervisor hierarchy.
  - nivertech 16y ago
    Sometimes you need just an FSM without attached process/thread with mailbox/queue (i.e. passive FSM). Then you have an API to dispatch events and query current state. For example if you have gen_server using FSM, with gen_fsm you will have 2 processes. If there was passive FSM module, you would save 1 process and handle twice as many simultaneous clients. Some examples from boost statechart library: http://www.boost.org/doc/libs/1_34_0/libs/statechart/doc/tutorial.html#BasicTopicsAStopWatch http://www.boost.org/doc/libs/1_34_0/libs/statechart/doc/tut... #include <boost/statechart/transition.hpp> // ... int main() { StopWatch myWatch; myWatch.initiate(); myWatch.process_event( EvStartStop() ); myWatch.process_event( EvStartStop() ); myWatch.process_event( EvStartStop() ); myWatch.process_event( EvReset() ); return 0; }
    - cyberlync 16y ago
      the fact that the gen_server is using a gen_fsm and that that requires two processes has little or no effect on the number of simultaneous clients you can have. Unless I am missing something, I am not quite sure why you are drawing that correlation.
      - nivertech 16y ago
        When you handling millions of Comet clients per node - every byte counts. And even that processes are lightweight in Erlang, they still take about 300 bytes of memory + State. FSM is abstract concept. When it's wrapped into Actor it's something else and not pure FSM. gen_fsm is more similar to Rational Rose "Capsule" design pattern, except that Capsule may have several message queues, while gen_fsm has only one. You can also mask/unmask events in Capsule. When many years ago I first learned Erlang I thought that every process will have built-in FSM as 1st class citizen (this is what I expected from programming language designed by Telecom company). Also what I would like from FSM module, is to be able just to specify state transition table (STT) including on entry/exit. Then the callback functions only handle state transition logic. Currently gen_fsm is very verbose for huge FSMs and I sure it's easy to introduce bugs when coding STTs. I think the reason most people don't use gen_fsm is because it's very basic and verbose, not because there is no need in built-in FSM behaviour in OTP.
kungfooguru 16y ago
Great stuff. I was just arguing on the ErlangCamp mailing list that the gen_fsm behaviour is great! I just sent this out to everyone.
burgerbrain 16y ago
I prefer name-brand flying spaghetti monsters actually.
- code_duck 16y ago
  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.

60 points by keyist 16y ago

mononcqc 16y ago

Author, here. I hope you enjoy.

pivo 16y ago
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!

chunkbot 16y ago

Good stuff. Compared to the more "popular" generic behaviours like gen_server, gen_fsm doesn't get a lot of attention. It's nice to see it added to your tutorial with this level of detail.

jerf 16y ago
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.

nivertech 16y ago

Too bad the new "Erlang and OTP in Action" book leaves gen_fsm out of scope. Anyway gen_fsm behavior is pretty weak comparing to FSM frameworks I used in C++: no on_entry / on_exit callbacks. Also, I'm not sure you can use gen_fsm sequentially by itself (i.e. without Erlang process).

kungfooguru 16y ago
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.
grogers 16y ago
What's wrong with spawning a separate process for the FSM? You will still typically have it linked in your supervisor hierarchy.
- nivertech 16y ago
  Sometimes you need just an FSM without attached process/thread with mailbox/queue (i.e. passive FSM). Then you have an API to dispatch events and query current state. For example if you have gen_server using FSM, with gen_fsm you will have 2 processes. If there was passive FSM module, you would save 1 process and handle twice as many simultaneous clients. Some examples from boost statechart library: http://www.boost.org/doc/libs/1_34_0/libs/statechart/doc/tutorial.html#BasicTopicsAStopWatch http://www.boost.org/doc/libs/1_34_0/libs/statechart/doc/tut... #include <boost/statechart/transition.hpp> // ... int main() { StopWatch myWatch; myWatch.initiate(); myWatch.process_event( EvStartStop() ); myWatch.process_event( EvStartStop() ); myWatch.process_event( EvStartStop() ); myWatch.process_event( EvReset() ); return 0; }
  - cyberlync 16y ago
    the fact that the gen_server is using a gen_fsm and that that requires two processes has little or no effect on the number of simultaneous clients you can have. Unless I am missing something, I am not quite sure why you are drawing that correlation.
    - nivertech 16y ago
      When you handling millions of Comet clients per node - every byte counts. And even that processes are lightweight in Erlang, they still take about 300 bytes of memory + State. FSM is abstract concept. When it's wrapped into Actor it's something else and not pure FSM. gen_fsm is more similar to Rational Rose "Capsule" design pattern, except that Capsule may have several message queues, while gen_fsm has only one. You can also mask/unmask events in Capsule. When many years ago I first learned Erlang I thought that every process will have built-in FSM as 1st class citizen (this is what I expected from programming language designed by Telecom company). Also what I would like from FSM module, is to be able just to specify state transition table (STT) including on entry/exit. Then the callback functions only handle state transition logic. Currently gen_fsm is very verbose for huge FSMs and I sure it's easy to introduce bugs when coding STTs. I think the reason most people don't use gen_fsm is because it's very basic and verbose, not because there is no need in built-in FSM behaviour in OTP.

kungfooguru 16y ago

Great stuff. I was just arguing on the ErlangCamp mailing list that the gen_fsm behaviour is great! I just sent this out to everyone.

burgerbrain 16y ago

I prefer name-brand flying spaghetti monsters actually.

code_duck 16y ago
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.