christhekeele

christhekeele

I ran into a situation recently where it would be very useful to start up a DynamicSupervisor in an application’s sup tree, always with a specific list of child specs to boot on init—much the way normal Supervisors work, but with the option to dynamically start new children easily later.

I started writing a question on how to do so… Which turned into an experiment with handle_continue (since DynamicSupervisor is implemented as a GenServer)… Which turned into a half-written proposal to the core mailing list… Which turned into an incomplete proof-of-concept fork implementing support for this within Elixir… Before discovering that during the development of DynamicSupervisor, support for this was intentionally dropped because of technical difficulties expanding child specifications at boot time.

Problem is, I’m not sure I understand the original motivation or the difficulties in doing so. Based on my toy branch I had no difficultly using the existing validate_child logic to expand child specs given at init, so either the implementation of DynamicSupervisor has changed enough to overcome the obstacles present when it was first created, or (more likely) I’m missing something obvious that still prohibits it today.

(The implementation in my fork uses handle_continue when it doesn’t need to, and in fact shouldn’t, but that’s the circuitous route I took to get here. It’d be reworked in a proper PR.)

Does anyone have any insight into if and why we couldn’t pass DynamicSupervisor’s init procedure a list of child specs to boot at start? Perhaps you can explain the original rationale in a way I understand better? (Without spam @'ing them) do any of the original implementers mind chipping in? I’m reluctant to work more on a PR/open a feature proposal in the core mailing list without fully understanding why this was decided against originally.

Showing Posts 1 to 7

josevalim

josevalim

Creator of Elixir

I would suggest to start a DynamicSupervisor with a Task under a rest_for_one supervisor. This way you can start children immediately after the supervisor boots. IIRC that was the main reason to keep the DynamicSupervisor API simpler, since this behaviour is not common and it can be easily replicated.

Phillipp

Phillipp

I also have a DynamicSupervisor which needs to start some children on app startup.

For that I used the module based DynamicSupervisor so I can hook into the init function like that:

  def init(_arg) do
    Manager.subject_server_startup()
    DynamicSupervisor.init(strategy: :one_for_one)
  end

My Manager is in itself a GenServer, here are some snippets from my code:

  def subject_server_startup() do
    GenServer.cast(__MODULE__, :subjects_supervisor_startup)
  end

  def handle_cast(:subjects_supervisor_startup, state) do
    for subject <- config() do
      start_subject(subject)
    end

    {:noreply, state}
  end
christhekeele

christhekeele OP

Ooh, that’s better than how I was doing this, thanks!

One interesting thing I realized while tinkering around with implementing support for this is that doing so makes the behaviour contract for DynamicSupervisor match that of Supervisor (by returning a list of children + options in init/1).

I agree this behaviour is not common and most apps don’t need such a feature, but it does provide a compelling ‘upgrade path’ from a Supervisor to DynamicSupervisor: just replace the module name in use Supervisor and Supervisor.init, with the knowledge that any callback returns crafted by hand (instead of Supervisor.init) will continue to work since both callbacks now accept the same shape.

Then you could begin converting a Supervisor to a DynamicSupervisor with the knowledge that any children you were relying upon to be started initially in your supervision tree still will be as you gradually refactor how they are launched.

Of course, this is solving a problem I don’t think exists, I just find the parity and parallels pretty—agreed it’s probably not worth complicating the implementation for. :smile:

iautom8things

iautom8things

Just in case someone else (like me) happens upon this thread looking for guidance, but doesn’t quite grok what José is suggesting (also like me, initially):

I happened to find this great TIL repo by @slashdotdash that gives you a working example:

https://github.com/slashdotdash/til/blob/master/elixir/dynamic-supervisor-start-children.md

Thank you, everyone! :bowing_man:

Linuus

Linuus

I tried this but it doesn’t seem to work? It just restarts my DynamicSupervisor and not my Task.
Is it because the Task has already finished so it can’t be “restarted”?

My Supervisor looks like this:

defmodule MyApp.ControllerSupervisor do
  use Supervisor

  require Logger

  def start_link(init_arg) do
    Supervisor.start_link(__MODULE__, init_arg, name: __MODULE__)
  end

  def init(_init_arg) do
    children = [
      {MyApp.DynamicControllerSupervisor, []},
      {Task,
       fn ->
         Logger.info("Task started")
         MyApp.DynamicControllerSupervisor.autostart_controller_connections
       end}
    ]

    Supervisor.init(children, strategy: :rest_for_one)
  end
end
edisonywh

edisonywh

I think it’s because of the restart strategy of the Task module, here’s the documentation:

Opposite to GenServer, Agent and Supervisor, a Task has a default :restart of :temporary . This means the task will not be restarted even if it crashes. If you desire the task to be restarted for non-successful exits, do:

You can simulate this by creating a Task module yourself,

defmodule MyTask do
  require Logger
  # use Task, restart: :transient
  use Task

  def start_link(arg) do
    Task.start_link(__MODULE__, :run, [arg])
  end

  def run(arg) do
    Logger.info("Hello")
  end
end

Then put in in your supervision tree like normal {MyTask, []}. Kill the first process and you’ll see that MyTask doesn’t restart, then now try with the restart: :transient flag, and you’ll see it works

brentjanderson

brentjanderson

This thread helped me recently, and I wanted to add in that a Task will run asynchronously, whereas you can do the same thing with an Agent.

defmodule MyApp.SomeSupervisor do
  use Supervisor

  require Logger

  def start_link(init_arg) do
    Supervisor.start_link(__MODULE__, init_arg, name: __MODULE__)
  end

  def init(_init_arg) do
    children = [
      {DynamicSupervisor, name: __MODULE__.DynamicSupervisor, strategy: :one_for_one},
      {Agent, # If you want this to run asynchronously, change this to Task
       fn ->
         Logger.info("Task started synchronously")
         
         {:ok, _pid} = DynamicSupervisor.start_child(__MODULE__.DynamicSupervisor, child_spec)

         %{} # Returning an empty state here
    ]

    Supervisor.init(children, strategy: :rest_for_one)
  end
end

If you want to block while adding the initial children to the DynamicSupervisor, this is one way to do it.

— All posts loaded —

Where Next? Top

Trending in Questions Top

stjefim
Hello! Suppose you are building workflow (order / task / payment) processing system with the following requirements: Each workflow con...
New
water
I’m aware of 2 such projects, are there others? git: GitHub - team-alembic/realworld: A fullstack Phoenix LiveView application with back...
New
itzmidinesh
Hi all, I’m working on a Phoenix project where I need to make external HTTP requests and I’m trying to choose between Req and HTTPoison....
New
peck
Hi everyone. My team and I have been working on a fairly modest app based around video streaming and chat, but we’ve landed a customer t...
New
leoschweizer
Hi, we run different LLM models across a cluster, with each node loading a configurable subset. Model-specific queues let nodes consume ...
New
csmr
Hi all, I’m new here and would like to hear peoples views on my Elixir/Phoenix based game-engine! :smiley: Mutonex gamedesign was finish...
New
Stef-Verniers
Hello I’ve been coding in Elixir for almost two years now because of my current job where we implemented Elixir in our application. But ...
New

Other Trending Topics Top

dominicletz
Hey there, I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first. ...
New
mudasobwa
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New
OndrejValenta
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly) AI dream has many faces, but general...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews