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.
