[erlang-questions] "calling" a gen_fsm

Theepan vasdeveloper@REDACTED
Wed Sep 23 12:56:21 CEST 2015


I don't think it is a good idea to separate the state maintenance from the
real work that is happening, unless you have a strong reason for it. What
happens if you separate them is that you are keeping a process just for
state maintenance, and most of the time the gen_fsm process is going to be
idle. Other drawback is that the worker process will have to constantly
check the state machine to ensure that it doing work at the correct state.
There is a chance of off state processing and it is hardware hungry.

There are places where you will separate the state maintenance, for
instance many workers depending on a single state. At the low level gen_fsm
and gen_tcp are just Erlang process, and what you are trying to do right
now is good for what you are doing.

Theepan




On Wed, Sep 23, 2015 at 9:31 AM, Garry Hodgson <garry@REDACTED>
wrote:

> On 9/22/15 3:02 PM, Roger Lipscombe wrote:
>
>> On 22 September 2015 at 18:37, Garry Hodgson <garry@REDACTED>
>> wrote:
>>
>>> thanks to both of you for your quick and helpful answers.
>>> gotta love this list.
>>>
>> Both Theepan and Vance are correct in that this is a useful way to
>> build this kind of thing. In fact, there's a good example (using a
>> gen_server, rather than a gen_fsm) here:
>>
>> https://erlangcentral.org/wiki/index.php?title=Building_Non_Blocking_Erlang_apps
>>
> very nice.
>
>> I'd just add one point, though: I recently built something similar,
>> and I found it simpler to separate the client into two processes: one
>> gen_fsm to handle the state machine, and a separate gen_server to
>> handle the decoding and framing.
>>
> i briefly considered that, but it wasn't obvious how to divide the
> work between the two. i'd be interested in how you did, if you'd
> care to elaborate.
>
> thanks
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150923/a0e6949c/attachment.htm>


More information about the erlang-questions mailing list