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

[Fred Hebert]

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