sergey-chechaev
Hello, I don’t find any common approach to start heavy work or children’s processes after DynamicSupervisor started. When we restart application or DynamicSupervisor is crash, we need to start DynamicSupervisor children’s processes or do heavy work as the handle_continue function when we use GenServer. In our project, we use start_link for this:
defmodule SomeDynamicSupervisor do
use DynamicSupervisor
alias SomeGenServer
def start_link(_) do
with link <- DynamicSupervisor.start_link(__MODULE__, %{}, name: __MODULE__) do
Task.async(fn -> start_child_processors() end)
link
end
end
def init(_) do
DynamicSupervisor.init(strategy: :one_for_one, max_restarts: 10)
end
def start_child_processors do
SomeLogic.list_of_ids()
|> Enum.each(&init_processor/1)
end
def init_processor(some_id) do
opts = [name: NameGenerator.processor_registry_name(some_id)]
DynamicSupervisor.start_child(__MODULE__, %{
id: "#{SomeGenServer}_#{some_id}",
start: {SomeGenServer, :start_link, [opts]}
})
end
end
What pitfalls does this approach have? Perhaps there is a better way. Can anyone share it with me?
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
Why would you use a DynamicSupervisor is instead of a static/normal one here? It feels like a normal supervisor would suite your need better.
sergey-chechaev
I need to create processes dynamically. But it’s not matter. My question what the best practice to start a bunch of children processes when we start
DynamicSupervisor.kwando
I would nest the DynamicSupervisor under another Supervisor with the strategy
:rest_for_oneand also add a setupTaskafter the DynamicSupervisor in that supervisor.If your DynamicSupervisor crash it will be detected by the
Supervisor.sergey-chechaev
Great, we also considered this option. But we wanted to make it a little easier for understanding and putted the warm-up function to
DynamicSupervisor. Also,DynamicSupervisorstarted by application.ex so supervisor up it if it fails andDynamicSupervisorrun warm-up function itself. One best thing thatstart_linkguaranteed thatDynamicSupervisoris up.LostKobrakai
Ordering for supervisor children is guaranteed. If the process to start your task is after the
DynamicSupervisorchild then it will only run once theDynamicSupervisoris indeed successfully started. You’re not making this simpler, by trying to mush together different responsibilities.sergey-chechaev
Yes, maybe you are right that we need to share responsibility like suggest @kwando: