> 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? 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. For more options, visit https://groups.google.com/d/optout.
