News for hackers. Stuff that matters.
Re:Generic FSMs in Erlang by cyberlync on Tuesday December 21, 2010 @11:50AM (#2028360)
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.
Re:Generic FSMs in Erlang by nivertech on Tuesday December 21, 2010 @04:17PM (#2029431)
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.