[erlang-questions] The gen server simplified (how it works)
Torben Hoffmann
torben.lehoff@REDACTED
Wed Apr 20 23:44:48 CEST 2011
On Wed, Apr 20, 2011 at 15:09, Jeroen Koops <koops.j@REDACTED> wrote:
>
>> The most common form of gen _server abuse I have seen (and I plead guilty
>> of it myself) is attempting to turn it into something akin to a state
>> machine. My rule of thumb is if your state record contains a field called
>> state or something like it and you take different actions based on it, then
>> it's time to re-factor into a gen_fsm. It's easy to get into this situation
>> since things usually start simple and build up once more functionality is
>> piled on.
>>
>>
> I don't know about this -- I have written numerous gen_servers whose
> state-record include a state-field (although I usually call it 'current'),
> and events (calls, casts, infos) are handled differently depending on its
> value. The reason for not using a gen_fsm is that very often, an event
> should be handled in one way in one particular state, and in another way in
> _all_ other states. This is easy to do using pattern-matching when using a
> gen_server, but when using a gen_fsm you have no choice but to write out
> every state/event combination, which can become pretty cumbersome.
>
Then one can use an gen_fsm:send_all_state_event/2 and pattern match on both
state and state date that in the modules handle_event/3 function.
I have done that many times and it works rather well.
Cheers,
Torben
>
> On a related note, I have been moving away from using gen_servers all the
> time. The reason for this is that in a gen_server, the state consists of
> just the state term. In an arbitrary process, the state actually consists of
> the process' entire call-stack, and it makes the flow in code such as the
> almost proverbial:
>
> idle() ->
> receive
> { Number, incoming } ->
> start_ringing(),
> ringing(Number);
> off_hook ->
> start_tone(),
> dial()
> end.
>
> ... much easier to follow than when using a gen_server or gen_fsm.
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
--
http://www.linkedin.com/in/torbenhoffmann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110420/4d257d81/attachment.htm>
More information about the erlang-questions
mailing list