I’m wondering why you need two processes here in the first place. Couldn’t the lobby do it’s own countdown.

Friendly code

I can see you tried to do some homework and you have some options to go about. Before anything, I would recommend you have a look at the examples for “Elixir in Action” (2nd edition):

I would redirect your attention to the Database hierarchy. @sasajuric also uses GenServers and Registry with via tuples, so I believe that just checking 3 or 4 files from his code would already direct you in the right path (right path being what I would recommend xD )

Direct call from CountdownTimer to Lobby

I discourage this. This means that CountdownTimer needs to know about the implementation of Lobby. This is highly discouraged in Elixir, if yo want both processes to communicate, they should have public API’s.

Public API

I believe this is what you mean for your second approach. You have a public function countdown_completed that other processes can call. This is by far the preferred method in the community because you expose an API, which allows you to change the structure of the messages being passed without affecting clients. I would caution against using a cast (CountdownTimer needs to make sure that Lobby received the message after all, or the game will never start, right?) but overall this would be my choice.

PubSub

Having in mind you will only have 1 process subscribed to the countdown, I believe a PubSub would be overkill. PubSub is nice if several processes are interested in knowing that the CountdownTimer has ended. If you only need to notify 1 process, then you don’t need the added complexity of the PubSub pattern.

This is a valid question. The scope of the problem you have described could be solved with the Lobby process using Process.send_after/4 and simply process the “complete” msg value when it is returned via the handle_info/2 callback.

I’m not a fan of this because it seems to tie the two together a bit much.

Now lets say there is a good reason for the CountdownTimer process to exist - maybe because it somehow coordinates a UI display of the countdown timer.

You can take inspiration from send_after. So rather than defining Lobby.countdown_completed/0, you solve the problem in the CountdownTimer API when the countdown is initiated.

CountdownTimer.new_timer(completed_msg, time)

CountdownTimer will implement this as a call so it will get from for free.

• it can either use send_after itself with a {from, completed_msg} message value
• or store {from, completed_msg} in the process state for later

So when the time comes CountdownTimer simply uses GenServer.cast(from, completed_msg) to return the requested completed_msg value to the Lobby that requested the timer (which it then has to handle in its own handle_cast/2).

In this particular situation I think it’s fine as the CountdownTimer process really doesn’t care if the Lobby process has died. Furthermore the CountdownTimer could just slap a monitor onto each of its client processes so that it can cleanup their timers as soon as possible.

I have a simple auction application that implements a timer for bidding and I simply use Process.send_after/4 and handle_info/2, and store the timer with the rest of the auction state. My front end can make calls to the server as needed to get an updated timer value, and when the timer expires handle_info/2 receives the message, does some things and lets the front end know that the timer expired.

That works fine.

Because the auction server also needs to send a bunch of other messages to the front end I ended up implementing a PubSub type of thing later anyway, to which this approach fit in nicely since my application was already generating a message for timer expiration.

Honestly the most trying part of implementing that was thinking through the various values the timer could have (false, a number, nil) and handling them appropriately, because in my case the timer gets started/paused/reset frequently under different conditions.

Thanks all for your replies; they’ve been very helpful.

I’m mainly making CountdownTimer it’s own process because it seems like a separate concern to the lobby, which is mainly dealing with handing out the different roles in the game. I can definitely see the argument for merging the two, but in my head it seems a bit cleaner to separate them out.

I like this idea, but would it still work if the Lobby process is restarted for some reason? I’d expect the pid to be different then, so the from pid wouldn’t be correct. I’m also not sure how it’s different to the public Lobby.countdown_completed/1 function suggested by @Fl4m3Ph03n1x, which could call GenServer.cast itself.

Imho processes should be separated based on their runtime behaviour (error separation and stuff like that) and not on “concerns” like you’d separate classes by. The lobby and the timer are entangled in their runtime behavior so in my opinion there’s no reason to not run them in the same process.

Have a read through the following topic and the related article: To spawn, or not to spawn?

So, to summarize, in that post “thought concerns” refer to “I want to somehow organize a larger chunk of code, so it’s easier to work with”, while “runtime concerns” refer to “I want to get some observable runtime benefits, such as fault-tolerance, scalability, or potential for parallelism”.

Roughly (i.e. nothing is black and white):

• thought concerns → modules
• runtime concerns → processes

Also possibly:

I like this idea, but would it still work if the Lobby process is restarted for some reason?

The server argument for cast can be a name - so require that as an argument for new_timer.

The bigger issue is, how would a restarted Lobby process re-aquire the previous state (which may have been responsible for the last process crashing in the first place)? If the state is lost then the timer is meaningless.

I’m also not sure how it’s different

Coupling is significantly reduced.

CountdownTimer.new_timer(completed_msg, time) lets the client choose the exact format of the message to be handled by its own handle_cast/2 callback. And CountdownTimer isn’t coupled to the client module - not even at runtime.