<div dir="ltr">I'd echo Jesper's comments in saying that is most important to make sure the supervisor tree starts up quickly. There are several options I see:<div><br></div><div>1) Change A into an FSM (optional, but useful IMHO). Have its initial state be 'connect_to_hardware' with a timeout of 0 returned from init/1, e.g. {ok, connect_to_hardware, State, 0}. Then in 'connect_to_hardware', match timeout and do the connection there, then transition to the 'ready' state. Note that this state will be entered before any other messages are received, meaning that B and C should probably use sync_send_event to communicate with A.</div>
<div><br></div><div>2) Keep A as a gen_server, but do the same timeout trick in init/1. Have A connect in handle_info when receiving 'timeout', and then notify B and C that it's ready after.</div><div><br></div>
<div>3) Use Loic's proc_lib:init_ack + gen_server:enter_loop hack instead of the regular gen_server/gen_fsm flow. This is less clean, but allows you to do those slower blocky things at startup.</div><div><br></div><div>
I think the moral of the story is that starting up your system and implementing a protocol between processes should not be conflated. If there's a sequence of steps to be done with potential exit points or branches at each step, FSMs plus messages feels the most sane to me.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 5, 2013 at 7:19 AM, David Welton <span dir="ltr"><<a href="mailto:davidnwelton@gmail.com" target="_blank">davidnwelton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Fire up the supervisor tree as fast as possible, then do the connectivity. A<br>
> good example is how mnesia does it. You have to call<br>
> mnesia:wait_for_tables/1,2 in order to wait for tables to come online, but<br>
> the bootup of mnesia itself is very fast. So in your case, you would call:<br>
> hardware:wait_ready(arduino, 8000) to wait at most 8000ms for the arduino to<br>
> come online and so on.<br>
><br>
> There is a recent post by Fred Hebert on this subject,<br>
><br>
> <a href="http://ferd.ca/it-s-about-the-guarantees.html" target="_blank">http://ferd.ca/it-s-about-the-guarantees.html</a><br>
><br>
> you might want to read as well.<br>
<br>
</div>I already read it - it's a great post, as usual.<br>
<br>
However, perhaps I have not spelled out my problem very well.<br>
<br>
We have several bits of C code in external processes - let's call them<br>
A, B and C to be creative.  A starts, and does some stuff.  It's kind<br>
of slow to do it, so it'd be easy enough to just start it, and<br>
handle_info in the gen_server that supervises it to find out when it's<br>
really ready.  But B and C cannot start until A is ready.  So A should<br>
send messages to them, too?  I can see how to do it, but it all seems<br>
kind of complicated compared to just letting them start in the order<br>
they are supposed to start in, one after the other.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
David N. Welton<br>
<br>
<a href="http://www.welton.it/davidw/" target="_blank">http://www.welton.it/davidw/</a><br>
<br>
<a href="http://www.dedasys.com/" target="_blank">http://www.dedasys.com/</a><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>
</div></div></blockquote></div><br></div>