<div dir="ltr">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:<div>
<br></div><div><font face="courier new, monospace">handle_info(Info, _StateName, _StateData) -></font></div><div><font face="courier new, monospace">    Pid = get_pid(),</font></div><div><font face="courier new, monospace">    gen_fsm:send_event(Pid, Info).</font></div>
<div><br></div><div>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.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 5, 2013 at 9:12 AM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would consider having a middle-man process whose role is to deal with<br>
the NIF code, and turns messages received into gen_fsm events.<br>
<br>
Alternatively, the NIF could cheat and use the internal gen_fsm wrapping<br>
of messages ({'gen_event', Event}, where Event is the original message).<br>
the gen_fsm process will receive that message and think of it as if it<br>
were sent as an asynchronous event through the regular gen_fsm<br>
functions, and call your own custom states.<br>
<br>
This is a bit messier given you break the abstraction, but should be<br>
faster at run time than having a middle-man just forward stuff.<br>
<br>
Regards,<br>
Fred.<br>
<div><div class="h5"><br>
On 08/05, Janos Hary wrote:<br>
> All,<br>
><br>
><br>
><br>
> I'm working on an optical archiving application. I wrote a NIF wrapper<br>
> around a burning SDK. Other relevant parts are a task queue, which holds<br>
> burning or reading tasks, and a web based gui which shows the drives' state<br>
> to the user. In the middle sits an Erlang module controlling a physical<br>
> drive, and of cause the application should handle multiple drives.<br>
><br>
> Because the drives' state diagram is fairly complex (reading, burning,<br>
> handling different media capacities and types, hw events, errors, user<br>
> interactions on GUI or pressing the eject button, etc.) I started to<br>
> implement it as a gen_fsm.<br>
><br>
> Now, my problem: most of the events triggering a state change are coming in<br>
> plain Erlang messages (from the NIF, or from gproc what I use to connect to<br>
> the GUI module). I can capture these events with handle_info but I lose the<br>
> major advantage of the gen_fsm. If two subsequent events are coming through<br>
> handle_info, I vainly specify the new state, because the state's callback<br>
> won't be ever reached. My code is a bunch of handle_infos and they are just<br>
> handling the specific events in any state.<br>
><br>
> What is an advisabel practice to code such an FSM?<br>
><br>
><br>
><br>
> Thanks for any ideas in advance.<br>
><br>
> Janos<br>
><br>
<br>
</div></div>> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>