Long gen_server init question (not about order of messages :)

[Jesper Louis Andersen]

On Sat, May 15, 2021 at 8:55 PM Stanislav Ledenev <s.ledenev@REDACTED>
wrote:

>
> mod_api accepts requests and transforms them to calls to mod_x, mod_y.
> mod_func is crucial for the application but it needs a time consuming
> procedure
> of initialization. IRL it is some cryptography related stuff.
>
While mod_func is in the initialization state, mod_api must return
> 'not_ready' for all requests.
> While mod_func initializing it is not available for any requests.
>
>
I'd definitely go with Roger's idea.

Spawn mod_func as part of a supervision tree. This starts out as the proxy.
It spawns mod_func_bg which does the block and the initialization. While
initialization is ongoing, mod_func responds not_ready, and will do so with
a low latency. Once mod_func_bg is done, it sends its data to mod_func. Now
mod_func "becomes" the real process, and can answer requests. This avoids
the proxy in the common path.

In this solution the "notification" *is* the data.

A crash of mod_func repeats the process. You will go back to the not_ready
state. And once you are ready for processing, the state will flip with a
new notification from mod_func_bg. Failure in mod_func_bg can be detected
by a link (or monitor). I'd probably just link them. The two processes'
lifetimes are following each other anyway.


-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210518/5a41132d/attachment.htm>