On Sun, May 15, 2016 at 10:10 AM Eric Meadows-Jönsson <
[email protected]> wrote:
> > There are couple solutions to this problem. One is sending itself a
> message from init/1, which is error prone, because we have no
> guarantees that this will be the first message received by the
> process.
>
> What are the instances when a message can arrive before one sent from
> init/1?
>
Convention can provide fairly strong guarantees, but there are no absolute
ones. An example of it not being the first message:
def init(_) do
send other_process, {:new_pid, self}
send self, :connect
{:ok, nil}
end
In theory, there's a race condition there in which other_process could
attempt to send a message that arrives before :connect.
Aside from this example, are named processes registered before or after
init runs? if it's before, that's another avenue.
>
> On Sun, May 15, 2016 at 5:06 PM, Peter Hamilton <[email protected]>
> wrote:
>
>> One nitpick. Merge arg and state in the return in init. Having them
>> separate is confusing. Delayed init takes one parameter and returns a new
>> state. What happens to the originally returned state?
>>
>> On Sun, May 15, 2016, 7:23 AM James Fish <[email protected]> wrote:
>>
>>> I think the larger problem being tackled here is that current OTP
>>> behaviours require the callbacks to be purely message based and do not make
>>> it easy to dispatch internal events. Have you looked at :gen_statem in OTP
>>> 19 rc1? I think it solves this problem quite well, or at least I have not
>>> seen something I think is better. Once OTP 19 lands I'll release
>>> :gen_connection which is :connection but using a :gen_statem instead of a
>>> :gen_server. It simplifies the code enormously and works better with OTPs
>>> logging and debugging features. It might be that you want to propose
>>> including GenStatem instead of a delayed init.
>>>
>>> On 15 May 2016 at 15:20, Michał Muskała <[email protected]> wrote:
>>>
>>>> Yes, diverging from Erlang's gen_server is an issue, but we're already
>>>> doing that, albeit on a smaller scale. On the other hand this change
>>>> is purely extensible - if not used, it does not affect your code in
>>>> any way.
>>>>
>>>> As with most such things synchronous vs asynchronous initialization is
>>>> a tradeoff, I'd say it should be easily possible for the developers to
>>>> choose which guarantees interest them. Right now one is extremely easy
>>>> to achieve, and the other is rather complicated. I agree, though, that
>>>> synchronous initialization is a better choice in most circumstances,
>>>> but when you need async, well - you need it ;)
>>>> Another case for async initialization is that the synchronous one is
>>>> happening one process at a time. In case you have a lot of processes
>>>> that all need to load some state from database doing it concurrently
>>>> should be a huge improvement in the startup time. The guarantee of the
>>>> supervision tree is decreased only slightly if you have a process that
>>>> checks for the availability of the connection earlier in the
>>>> supervision tree.
>>>>
>>>> Doing this as a separate library was my initial idea, until I tried to
>>>> find a name and couldn't come up with anything satisfying other than
>>>> just "GenServer". At that point I decided to write this proposal
>>>> first, but doing it as a library is still something I'm considering.
>>>> Writing a proposal was also a way to gather opinions on usefulness of
>>>> such a library.
>>>>
>>>> 2016-05-15 15:34 GMT+02:00 Andrea Leopardi <[email protected]>:
>>>> > I'm not sure about this. It would make Elixir's GenServer different
>>>> from
>>>> > Erlang's gen_server, and I'm not sure that's ok. I agree that it's
>>>> nasty to
>>>> > do this correctly, but it's still very possible.
>>>> > Also, I would say that if you depend on said database
>>>> resources/expensive
>>>> > initialization for your application to function properly, than I
>>>> think it's
>>>> > ok to have a long initialization. Section 2.2 in chapter 2 of Erlang
>>>> in
>>>> > Anger has a very interesting discussion about this.
>>>> >
>>>> > Maybe this is more suited to an external library (similar to (gen
>>>> > :P)connection)?
>>>> >
>>>> >
>>>> > On Sunday, May 15, 2016 at 2:45:27 PM UTC+2, Michał Muskała wrote:
>>>> >>
>>>> >> Hello everybody,
>>>> >>
>>>> >> Today GenServer (and all stdlib behaviours) are initialized
>>>> >> synchronously - only after init/1 returns the start_link function
>>>> will
>>>> >> return. But in many places the initialization may be expensive or is
>>>> >> not essential to the GenServer's operation and can be, at least
>>>> >> partially, delayed.
>>>> >>
>>>> >> There are couple solutions to this problem. One is sending itself a
>>>> >> message from init/1, which is error prone, because we have no
>>>> >> guarantees that this will be the first message received by the
>>>> >> process. The other one is to use :proc_lib or :gen directly, similar
>>>> >> to how it's used in the connection library
>>>> >>
>>>> https://github.com/fishcakez/connection/blob/master/lib/connection.ex#L595
>>>> >> - this solution is correct, but very complicated and requires
>>>> advanced
>>>> >> knowledge of OTP internals.
>>>> >>
>>>> >> I'd like to propose adding another callback to GenServer called
>>>> >> delayed_init/1. that would be called if a new tuple {:delayed_init,
>>>> >> arg, state} is returned from init/1. The callback would be called
>>>> >> after start_link returned, but before any message is processed by
>>>> the
>>>> >> server.
>>>> >> The delayed_init/1 would support returning:
>>>> >> {:ok, state} - for entering normal GenServer loop
>>>> >> {:ok, state, timeout | :hibernate} - similar to init/1
>>>> >> {:stop, reason, state} - similar to the return value of call/3 and
>>>> cast/2
>>>> >>
>>>> >> This would allow to deal with the problem easily from application
>>>> code
>>>> >> and simplify libraries such as connection significantly, removing all
>>>> >> the OTP plumbing code.
>>>> >>
>>>> >> Example use cases include - opening sockets or ports, loading some
>>>> >> state from external resources like databases or doing some expensive
>>>> >> initialization that we know usually succeeds and that should not
>>>> block
>>>> >> starting the supervision tree, awaiting the start of other parts of
>>>> >> the supervision tree or other applications before processing
>>>> messages.
>>>> >>
>>>> >> What do you think about that?
>>>> >>
>>>> >> Michał.
>>>> >
>>>> > --
>>>> > You received this message because you are subscribed to the Google
>>>> Groups
>>>> > "elixir-lang-core" group.
>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>> send an
>>>> > email to [email protected].
>>>> > To view this discussion on the web visit
>>>> >
>>>> https://groups.google.com/d/msgid/elixir-lang-core/f766ac8f-a9e3-4bf7-a98a-ce280e7fd69e%40googlegroups.com
>>>> .
>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "elixir-lang-core" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGAFNpna5qHmtqaG4-tW%3DY%2B%2BhXJ%2B52PxPUreXiYCW7mCOcHyzA%40mail.gmail.com
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "elixir-lang-core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elixir-lang-core/CA%2BibZ99h84%2BA83V2jv2VWH5xFHLqAdmPfCgFQKSx7voh%2BKFJDA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/elixir-lang-core/CA%2BibZ99h84%2BA83V2jv2VWH5xFHLqAdmPfCgFQKSx7voh%2BKFJDA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/CAOMhEnzR_atxA_y2TCQu_W3ZrWjkhbO_RLn-%2BJ4Y2Z%3DAT1y2Sw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/CAOMhEnzR_atxA_y2TCQu_W3ZrWjkhbO_RLn-%2BJ4Y2Z%3DAT1y2Sw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Eric Meadows-Jönsson
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/CAM_eapgTK3ke5%3D9OJ61dDhU25tQ%2BWy7WFzj%3DHRsk-0%3D_LmAGEA%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAM_eapgTK3ke5%3D9OJ61dDhU25tQ%2BWy7WFzj%3DHRsk-0%3D_LmAGEA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAOMhEnwq9iFKMn3zCPHfVxqrsfMdAGE_y6TeRV-xP1_JF7UA1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
