"sample" an agent every second?

Hey all and future search engine visitors (like me). I wanted to mention something I feel was missed here. In case it matters to your program, you can ensure that your initial :tick message is sent after GenServer’s event loop is started by using the handle_continue/2 callback.

@impl true
def init(state) do
  {:ok, state, {:continue, :init}}
end

@impl true
def handle_continue(:init, state) do
  send(self(), :tick)
  {:noreply, state}
end

A state machine is also a good solution.

If you need to go fancy with timers, updating timers, postpone events, etc, you can checkout :gen_statem in erlang. It is basically a GenServer with lots of bells and whistles.

I would even go further…

  def init(_) do
    # compute init state
    period = 1_000
    ref = Process.send_after(self(), :tick, period)
    {:ok, %{period: period, tref: ref}}
  end

You can pause, resume, update the frequency rate…

Just send yourself a message using send_after then from the handler broadcast your state:

 def init(_) do
    # compute init state
    Process.send_after(self(), :tick, 1000)
    {:ok, state}
  end

def handle_info(:tick, state) do
    Phoenix.PubSub.broadcast(My.PubSub, "sample", {:sample, state})
    Process.send_after(self(), :tick, 1000)
end

It’s more common to use a map than a tuple for state…

Then it is easier to make pattern match…

%{chord: chord, tref: tref}
#
# You can pattern match nil tref with...
%{tref: nil}
# instead of 
{_, nil}
# and potentially, it's harder to remember where tref is.
{_, _, _, nil, _, _}

It’s also possible to do it with tuples, but it will be easier to pass from map to struct, than from tuple to struct. Unless You need to interface some Erlang record type, the Elixir way is to use a map.

The idea is to write a functional core, separate from any server logic.

BTW You can also replace 60000 with 60_000, it might be more readable.

It is also the case for Process.send_after, it returns a ref. And it is possible to read the elapsed time with Process.read_timer(ref), or cancel timer. I also store the ref in the server state.

Both are doing the same, but not the same way. I don’t use :timer module because it can get overloaded.

From Common Caveats — Erlang System Documentation v29.0.2

Creating timers using erlang:send_after/3 and erlang:start_timer/3, is much more efficient than using the timers provided by the timer module in STDLIB.

Not sure how to do that - the intention to do this resulted in timer, genserver, message etc.
I receive a message, then update some internal state. the “poller” or “sampler” is acting on that updated state. I’m just using one module now and I spawn the timer from there directly. Could you show how you would make it simpler?

Since you are already using a PubSub, why don’t you just broadcast from the first GenServer every second using a different topic and let whatever interested party subscribe to it.

If you have to do polling, I’d skip GenServer, timer, sending yourself a message, etc, in the poller altogether, and just spawn off a plain process that sleeps periodically.

This is what I went with:

  @doc """
  :param tempo: integer, beats per minute (# of times chord plays per minute)
  """
  def init(tempo) when is_integer(tempo) do
    Phoenix.PubSub.subscribe(:inputs, "dots")
    {:ok, {nil, generate_tick(tempo}}
  end
  def handle_cast({:tempo, tempo}, {chord, tref}) do
    :timer.cancel(tref)
    {:noreply, {chord, generate_tick(tempo)}}
  end
  defp generate_tick(tempo) do
    {:ok, ref} = :timer.apply_interval(trunc(60000/tempo), __MODULE__, :play, [self])
    ref
  end