Github user iilyak commented on a diff in the pull request:
https://github.com/apache/couchdb-chttpd/pull/115#discussion_r60446470
--- Diff: src/chttpd_auth_cache.erl ---
@@ -95,7 +95,8 @@ get_from_cache(UserName) ->
%% gen_server callbacks
init([]) ->
- {ok, #state{changes_pid = spawn_changes(0)}}.
+ self() ! {start_listener, 0},
--- End diff --
There are five ways to deal with delayed initialization.
1. send a message to itself and handle it in handle_info.
2. do gen_server:cast to itself.
3. return `{ok, State, 0}` and implement `handle_info(timeout, ..`
4. use `proc_lib:start_link -> proc_lib:init_ack -> gen_server:enter_loop`
In this particular case we don't have any functions which use this
gen_server (handle_call and handle_cast are empty and handle_info handles one
specific case which wouldn't be a problem). So we don't care that someone would
call us while we are not having changes_pid set. This means that `#4` is
overkill for sure. Since we already handle `start_listener` event in
handle_info it is easiest to use approach `#1`.
In cases when there are none empty handle_call or handle_cast and
gen_server is anonymous I usually choose `#2` (i.e. `gen_server:cast(self(),
init)`). Since nobody would be able to call us anyway because our gen_server
doesn't have name and pid is not known to the potential caller. By the time we
provide the pid to the potential caller init message would be in the process
mailbox (because init is executed in the context of that process). Therefore
the very first message gen_server will be processing would be `init` message. I
would never use `#3` since it does rely on `timeout` atom which doesn't let you
to clarify you intend. `#4` is only useful for named processes. Because in
this case you might get messages from potential callers before you place `init`
message into process mailbox.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
