Simply pass the rate frequency as part of the server state. So You can modify it.

There is also Process.send_after.

There is an example in this tetris in Erlang, where the game loop accelarate over time.

http://www1.erlang.org/examples/small_examples/tetris.erl

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 Erlang -- Common Caveats

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.

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

You probably want a more complex scheduler for this. Eg. Oban or Quantum.

If you don’t want something so heavyweight, you can just create a sampling genserver and in the init use :timer.send_interval/2 Erlang -- timer

How do I make it possible for the supervision tree to treat both of these processess together as a “single process” that can be shut down together?

change the strategy from :one_for_one to :one_for_all. Or maybe :rest_for_all.

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