<div class="gmail_quote">On Wed, Aug 24, 2011 at 4:51 PM, Ladislav Lenart <span dir="ltr"><<a href="mailto:lenartlad@volny.cz" target="_blank">lenartlad@volny.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hello.<div><br>
<br>
> I was told that the timeout=0 reply from init/1 is has some implicit<br>
> behavior that might be useful: it ensures that the<br>
> handle_info('timout', State) is called before any other messages can<br>
> be dispatched, which gives you a hook from init/1 that will run after<br>
> the call to gen_server:start_link has returned. Feels hacky, to me --<br>
> but the only way to handle certain cases.<br>
<br></div>
Just a side note to the special meaning of timeout=0 in init: the same<br>
applies to any message sent to self() from the init/1 function, because<br>
noone else knows my pid yet.<br><font color="#888888">
<br>
<br>
Ladislav Lenart</font><div><div></div><div><br></div></div></blockquote><div> </div><div>Hi! </div><div><br></div><div>Returning a timeout of 0ms from the init/1 callback does not guarantee that a timeout message is "sent" to the handle_info function before any other messages are processed.</div>
<div><br></div><div>If you for example registered the process in the init/1 callback, in the process registry or another facility that would make your process visible to other processes, you may return from the init/1 callback with a non-empty message queue. In this case these messages will be processed by your gen_server, you will not receive a timeout message after this.</div>
<div><br></div><div>MVH Magnus Klaar</div></div>