[erlang-questions] gen_server and init
Tue Jul 28 21:24:48 CEST 2015
On 07/28/2015 11:33 AM, Ali Sabil wrote:
> 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.
The gen_server:enter_loop function does not return and the init/1 function must return, to show initialization succeeded.
> On Tue 28 Jul 2015 at 18:44 Michael Truog <mjtruog@REDACTED <mailto: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> <mailto:jesper.louis.andersen@REDACTED> wrote:
>> On Tue, Jul 28, 2015 at 11:23 AM, Loïc Hoguin <essen@REDACTED <mailto: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 list
>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
> erlang-questions mailing list
> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions