Implemented this way, options like max_restarts max_children and so on
would occur per partition. I take it the plan would be to simply note that
in the docs? I don't see any easy way to enforce those values across all
partitions, which I think is just fine.
which_children/1 and so on won't work as expected either, so maybe we want
a helper function inside of DynamicSupervisor that flat_maps that over the
child supervisors?
Overall though, +1 from me.
On Thursday, September 2, 2021 at 11:28:19 AM UTC-4 José Valim wrote:
> Given supervisors are also processes, they may also become bottlenecks.
> While this is unlikely to happen to a Supervisor, since it is mostly
> static, it can happen to a DynamicSupervisor.
>
> We can address this by partitioning the dynamic supervisor. Imagine the
> following dynamic supervisor:
>
> defmodule MyApp.DynamicSupervisor do
> use DynamicSupervisor
>
> def start_link(opts) do
> DynamicSupervisor.start_link(__MODULE__, arg, opts)
> end
>
> def init(_arg) do
> DynamicSupervisor.init(strategy: :one_for_one)
> end
> end
>
> In order to partition it, we can start 8 instances of said supervisor
> inside a regular Supervisor, and then pick one partition at random when
> starting a child. For example:
>
> defmodule MyApp.Supervisor do
> use Supervisor
>
> @partitions 8
> @name __MODULE__
>
> def start_child(module, arg) do
> i = :erlang.phash2(self(), @partitions) + 1
> DynamicSupervisor.start_child(:"#{__MODULE__}#{i}", {module, arg})
> end
>
> def start_link do
> Supervisor.start_link(__MODULE__, arg, name: @name)
> end
>
> def init(arg) do
> children =
> for i <- 1..@partitions do
> name = :"#{__MODULE__}#{i}"
> Supervisor.child_spec({MyApp.DynamicSupervisor, name: name}, id:
> name)
> end
>
> Supervisor.init(children, strategy: :one_for_one)
> end
> end
>
> I would like to make the above more convenient by introducing a
> :partitions option to DynamicSupervisor.start_link. When given, the new
> option will automatically start N dynamic supervisors under a supervisor,
> like above:
>
> DynamicSupervisor.start_link(__MODULE__, :ok, partitions: 8, name: @name)
>
> For now, the :name option will be required.
>
> Now, when spawning child processes, you will use via tuples:
>
> DynamicSupervisor.start_child({:via, DynamicSupervisor, {@name, self()}},
> {module, arg})
>
> The via tuple has the format {:via, DynamicSupervisor, {supervisor_name,
> value_to_partition_on}}. Once invoked, it will take care of partitioning
> based on the current process and dispatching it.
>
> Overall, encapsulating the partitioning of DynamicSupervisor (and
> consequently of Task.Supervisor) into an easy to use API can help to
> vertically scale up applications that use those constructs.
>
> ## Open questions
>
> One of the confusing aspects of the above is that the :name option no
> longer reflects the name of the DynamicSupervisor but of the parent
> Supervisor. One alternative is to *not* accept the :name option when
> :partitions is given, instead we could have a :root_name option instead (or
> something more appropriately named).
>
> Implementation wise, we will store the available processes in ETS or using
> a Registry (to be started alongside the Elixir application).
>
> Feedback?
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/bae8be24-a2e5-4a07-89db-7758ccfaf0d4n%40googlegroups.com.
