Async init call seems like a bad idea… Perhaps it’s sometimes necessary, just as cutting ones arm off might be in extreme situations ; ) - just trolling, would like to hear more.
https://michal.muskala.eu/2018/06/20/my-otp-21-highlights.html
From the article:
This will do just what you wanted from the beginning - execute the async initialization code before accepting any message, but allow parent supervisor to continue execution. No race conditions possible - “it just works” ™️!
OK, perhaps it makes sense. Teaches me for firing off a post before reading the full article…
1 Like
I think it expresses actually what you want when trying to use send’s inside the init or right after creation of a genserver, which is start and this is your first message, but what was actually expressed with send was start and here's a message which could end up in race conditions.
Extracting keys from maps in ets also seems like a great addition
2 Likes
It is amazing; but one have to be carefull because if the awaited continuation takes a long time—say 5 seconds—other processes that are awaiting a response from a handle_call might timeout. I quite like it because it formalize the use of selective receives in gen_servers.
1 Like
A common scenario for lazy init is establishing a connection to an external system like a database or a message broker. You don’t want to establish the connection in the init because it may fail and you then loose the ability for your supervisor to recover that process.
5 Likes
