Send_later to Agent

Questions / Help
, ,
1

I like to make use of Process.send_later to send a message to an Agent.
When I understand this tutorial right than one needs to implement handle_info to handle the message send by send_after. Agent doesn’t implement handle_info. Only gen_server does so.

As an example one could use the counter from the documentation:

defmodule Counter do
  use Agent

  def start_link(initial_value) do
    Agent.start_link(fn -> initial_value end, name: __MODULE__)
  end

  def value do
    Agent.get(__MODULE__, & &1)
  end

  def increment do
    Agent.update(__MODULE__, &(&1 + 1))
  end
end

Counter.start_link(1)

Process.send_after(Counter,:increment,1000)
2

Just don’t use Agent if you want to handle your own messages.

1 Like
3

Actually i want to use send_after from another process.

4

I think that’s what @hauleth is saying, if you need to receive messages on the Agent, then it’s not the right thing to use.

There’s several abstractions already written in both erlang and elixir and they all have a sort of “utility field”.

Agents are for keeping/retrieving state. GenServers are generic server interfaces, so they’re modelled as a behaviour that you can customise to handle your own message needs.

They can also do a slight impersonation of a state machine, but if you need actual state machine semantics, timeouts, stepped flows, etc then probably it’s easier to write a proper gen_statem which is an abstracted behaviour for that exact thing instead of shoehorning that into a gen_server, Tasks are for doing something and exiting, and so on.

If you need your Agent to receive messages and handle them then you’re either looking at gen_server or writing your own simple process to handle it (usually you’ll want the gen_server as its interface handles a lot of things for you)

1 Like
5

I still think that Agent is quite efficient (in terms of lines to be written compared to GenServer) and i think it makes sense to update its state in the future. I solved my need for now using :timer.apply_after/4.
In terms of processing power its not efficient.
The Erlang documentation highlights that Process.send_after is more efficient than :timer.apply_after/4 . I guess that GenServer is more efficient than Agent. Am I right about this?

6

Agent is thin wrapper over GenServer, so the performance should be similar.

And your example using GenServer will not be much more complex:

defmodule Counter do
  use GenServer

  def start_link(initial_value) do
    GenServer.start_link(__MODULE__, initial_value, name: __MODULE__)
  end

  def value, do: GenServer.call(__MODULE__, :get)
  def increment, do: GenServer.call(__MODULE__, :inc)

  @impl true
  def init(value), do: {:ok, value}

  @impl true
  def handle_call(:inc, state), do: {:reply, :ok, state + 1}
  def handle_call(:get, state), do: {:reply, state, state}
end
4 Likes
7

But doesn’t sending functions as messages makes sending more expensive?

8

You send functions as a messages in Agent case. So if it is indeed true (I highly doubt that if these messages are on local machine) then GenServer will be more performant one, as it send just simple atoms.

1 Like
9

Many don’t use Agent (and prefer GenServer), and many don’t use :timer library (and prefer Process.send_after, or similar) :slight_smile:

http://erlang.org/doc/efficiency_guide/commoncaveats.html

This is something You might learn from experience.

2 Likes
10

Does Process.send_after/3 work if the calling process quit before the timeout? If I want to do something similar, I’d cast a delay_update message to my gen_server, and within my gen_server I will Process.send_after/3 to self() to postpone the update. It involves 2 messages but it feels safer.

11

What you mean by “works”? It will not fail, but the message will be discarded, as there is no receiver.

1 Like
12

What I mean is if the receiver is still living, but the sender quit. Eg: I am calling Process.send_after/3 from a short live process such as in my Phoenix controller context, to a GenServer that is long living.

My understanding is the cost of :timer come from the fact that it is using a central process for all timer actions. Process.send_after/3 has lower cost, so there should not be a intermediate process, right? So who will send the message when the time finally comes? The original process? What if it quit already?

13

Try this out in iex

a = spawn(fn ->
  receive do
    :hi -> IO.puts(:ok)
  end
end)

b = spawn(fn ->
  Process.send_after(a, :hi, 1000)
end)

Process.alive?(b)

Process.send_after/4 calls :erlang.send_after/4 which is implemented as a BIF. See otp/erl_hl_timer.c at master · erlang/otp · GitHub

1 Like
14

Agent is made of GenServer; if you need the semantics that it supplies (a piece of mutable state that can be atomically updated) then it has the same performance because it’s the same code.

1 Like
15

Thanks, So Process.send_after works even after the calling process is dead. There is some BEAM level book keeping that make sure the message got send when the time is mature.

16

Process.send_after/4 looks up the pid from registered name at the time of timer expiration. So Process.send_after(Crap, :hi, 1000) will always succeed. And the message will be silently dropped because there is no such process. In comparison, if you send(MyGenServer, {:delayed_hi, 1000}) and in the GenServer you handle the custom message with a Process.send_after(self(), ...) it will be safer because:

  • If you mis-typed the name in the first send, the sending process will crash
  • The second send to self() has no lookup and will not drop message so long as it is still alive.
1 Like