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