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.

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

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.

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.