<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/28/2015 04:03 AM, Dmitry Belyaev
wrote:<br>
</div>
<blockquote
cite="mid:9B4937EE-6AC4-4804-878C-A599B3F3CEEA@gmail.com"
type="cite">Using timeout is definitely a bad idea. Sending init
message is a much better choice until the process is not
registered under well known name. In this case the process might
receive a message before the init message in the init function is
put into the mailbox.<br>
</blockquote>
If the first thing you do in the init/1 function is send a message
to self(), and you are not registering the process with
global/local/via using the start_link function of an Erlang/OTP
behaviour, then the message you send should be the first message in
the process' queue to be processed once the init/1 function returns
successfully and the process gets to its loop. The gen module shows
that name registration happens before the init/1 function is called,
so that can create the race condition that was previously described,
though there is nothing preventing you from doing the same
registration within the body of the init/1 function.<br>
<br>
<blockquote
cite="mid:9B4937EE-6AC4-4804-878C-A599B3F3CEEA@gmail.com"
type="cite">
-- <br>
Best wishes,<br>
Dmitry Belyaev<br>
<br>
<div class="gmail_quote">On 28 July 2015 7:41:53 PM AEST, Jesper
Louis Andersen <a class="moz-txt-link-rfc2396E" href="mailto:jesper.louis.andersen@gmail.com"><jesper.louis.andersen@gmail.com></a> wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jul 28, 2015 at 11:23 AM,
Loïc Hoguin <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">That
is however assuming there are only two processes in
your system, and everything is well written and pids
don't wrap up (which they apparently do?)</blockquote>
<div><br>
</div>
<div>I don't think adding more processes can tickle a
bug which is not found by two processes here. If I
have N processes racing for this, only one has to go
before. Once I know which, I can ignore all the other
processes. So the problem can be reduced to a
2-process model I think. <br>
</div>
</div>
<br>
</div>
<div class="gmail_extra">Pids internally have a 28 bit
structure so wrap-around can occur if you manage to
generate 268 million processes, and come ar ound
again. It depends a lot on your internal architecture if
this will happen or not in a practical setting.<br>
<br>
The scenario is that an old process might have been
holding on to an old Pid and tries to reuse it and now a
new process exist in its name.<br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">268 million sounds way too low on a
64 bit architecture however. There you have 60 bits rather
than 28, so you would not hit any limit at all were these
used. There is some effort in switching over however. If
you've hit these limits, I think it is worthwhile to
mention that you did. As systems grow ever more
complicated, earlier ceilings will eventually be hit and
knowing in advance it can happen is nice.<br>
<br clear="all">
</div>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</body>
</html>