[erlang-questions] gen_server and init

[Ali Sabil]

I would recommend taking a look at gen_server:enter_loop as an alternative
to sending a message to the process itself. It's a much cleaner alternative
imho.
On Tue 28 Jul 2015 at 18:44 Michael Truog <mjtruog@REDACTED> wrote:

> On 07/28/2015 04:03 AM, Dmitry Belyaev wrote:
>
> 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.
>
> 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.
>
>
>  --
> Best wishes,
> Dmitry Belyaev
>
> On 28 July 2015 7:41:53 PM AEST, Jesper Louis Andersen
> <jesper.louis.andersen@REDACTED> <jesper.louis.andersen@REDACTED>
> wrote:
>>
>>
>> On Tue, Jul 28, 2015 at 11:23 AM, Loïc Hoguin <essen@REDACTED> 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 ar ound 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.
>>
>>
>
> _______________________________________________
> erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions
>
>
>  _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150728/49038a51/attachment.htm>