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