tarearbol v0.9.5 Tarearbol.DynamicManager behaviour View Source

The scaffold implementation to dynamically manage many similar tasks running as processes.

It creates a main supervisor, managing the GenServer holding the state and DynamicSupervisor handling chidren. It has a strategy :rest_for_one, assuming that if the process holding the state crashes, the children will be restarted.

Typically one calls use Tarearbol.DynamicManager and implements at least children_specs/0 callback and receives back supervised tree with a state and many processes controlled by DynamicSupervisor.

To see how it works you might try

defmodule DynamicManager do
  use Tarearbol.DynamicManager

  def children_specs do
    for i <- 1..10, do: {"foo_#{i}", DynamicManager}, into: %{}
  end
end

{:ok, pid} = DynamicManager.start_link()

Link to this section Summary

Callbacks

This function is called to retrieve the map of children with name as key and a workers as the value.

Declares an instance-wide callback to report state; if the startup process takes a while, it’d be run in handle_continue/2 and this function will be called after it finishes so that the application might start using it.

Declares a callback to report slow process (when the scheduler cannot process in a reasonable time).

The main function, doing all the job, supervised.

Link to this section Callbacks

Link to this callback

children_specs()

View Source (since 0.9.0)
children_specs() :: %{required(binary()) => Enum.t()}

This function is called to retrieve the map of children with name as key and a workers as the value.

The value must be an enumerable with keys among:

  • :payload (passed as second argument to perform/2, default nil)
  • :timeout (time between iterations of perform/2, default 1 second)
  • :lull (threshold to notify latency in performing, default 1.1 (the threshold is :lull times the :timeout))

This function should not care about anything save for producing side effects.

It will be backed by DynamicSupervisor. The value it returns will be put into the state under children key.

Link to this callback

handle_state_change(state)

View Source (since 0.9.0)
handle_state_change(state :: :down | :up | :starting | :unknown) ::
  :ok | :restart

Declares an instance-wide callback to report state; if the startup process takes a while, it’d be run in handle_continue/2 and this function will be called after it finishes so that the application might start using it.

If the application is not interested in receiving state updates, e. g. when all it needs from runners is a side effect, there is a default implementation that does nothing.

Link to this callback

handle_timeout(state)

View Source (since 0.9.5)
handle_timeout(state :: map()) :: any()

Declares a callback to report slow process (when the scheduler cannot process in a reasonable time).

Link to this callback

perform(id, payload)

View Source (since 0.9.0)
perform(id :: binary(), payload :: term()) :: any()

The main function, doing all the job, supervised.

It will be called with the child id as first argument and the payload option to child spec as second argument (defaulting to nil, can also be ignored if not needed).

perform/2 must return :halt if it wants to be killed or anything else to be treated as a result.