[erlang-questions] gen_server and init

Dmitry Belyaev <>
Tue Jul 28 13:03:49 CEST 2015


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.
-- 
Best wishes,
Dmitry Belyaev

On 28 July 2015 7:41:53 PM AEST, Jesper Louis Andersen <> wrote:
>On Tue, Jul 28, 2015 at 11:23 AM, Loïc Hoguin <>
>wrote:
>
>> 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?)
>
>
>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.
>
>Pids internally have a 28 bit structure so wrap-around can occur if you
>manage to generate 268 million processes, and come around again. It
>depends
>a lot on your internal architecture if this will happen or not in a
>practical setting.
>
>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.
>
>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.
>
>
>-- 
>J.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>erlang-questions mailing list
>
>http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150728/63dd304f/attachment.html>


More information about the erlang-questions mailing list