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

[Janos Hary]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130805/6a7f2e4e/attachment.htm>