[erlang-questions] gen_fsm + handle_info = spaghetti code?

[Kolo Rahl]

I'm not sure what your NIF messages look like versus what your state
handlers take, but if you have a single gen_fsm and you store it in a
global registry, like with gproc, couldn't you have a single handle_info
call that retrieves your Pid and passes along the data in a
gen_fsm:send_event call? Example:

handle_info(Info, _StateName, _StateData) ->
    Pid = get_pid(),
    gen_fsm:send_event(Pid, Info).

Then you just need to make sure you register the pid and that your handlers
are set up correctly for whatever data is being piped through. I have not
actually done something like this before, so I can't conclusively say it
works or is the right way to go. Perhaps someone else with more experience
than I could comment if this is a reasonable solution.



On Mon, Aug 5, 2013 at 9:12 AM, Fred Hebert <mononcqc@REDACTED> wrote:

> I would consider having a middle-man process whose role is to deal with
> the NIF code, and turns messages received into gen_fsm events.
>
> Alternatively, the NIF could cheat and use the internal gen_fsm wrapping
> of messages ({'gen_event', Event}, where Event is the original message).
> the gen_fsm process will receive that message and think of it as if it
> were sent as an asynchronous event through the regular gen_fsm
> functions, and call your own custom states.
>
> This is a bit messier given you break the abstraction, but should be
> faster at run time than having a middle-man just forward stuff.
>
> Regards,
> Fred.
>
> On 08/05, Janos Hary wrote:
> > All,
> >
> >
> >
> > I'm working on an optical archiving application. I wrote a NIF wrapper
> > around a burning SDK. Other relevant parts are a task queue, which holds
> > burning or reading tasks, and a web based gui which shows the drives'
> state
> > to the user. In the middle sits an Erlang module controlling a physical
> > drive, and of cause the application should handle multiple drives.
> >
> > Because the drives' state diagram is fairly complex (reading, burning,
> > handling different media capacities and types, hw events, errors, user
> > interactions on GUI or pressing the eject button, etc.) I started to
> > implement it as a gen_fsm.
> >
> > Now, my problem: most of the events triggering a state change are coming
> in
> > plain Erlang messages (from the NIF, or from gproc what I use to connect
> to
> > the GUI module). I can capture these events with handle_info but I lose
> the
> > major advantage of the gen_fsm. If two subsequent events are coming
> through
> > handle_info, I vainly specify the new state, because the state's callback
> > won't be ever reached. My code is a bunch of handle_infos and they are
> just
> > handling the specific events in any state.
> >
> > What is an advisabel practice to code such an FSM?
> >
> >
> >
> > Thanks for any ideas in advance.
> >
> > Janos
> >
>
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130805/5c8debdd/attachment.htm>