Re: Supervisor and configuration update — how to do it?
Fri May 22 06:33:14 CEST 2020
On 2020/05/20 14:36, Max Lapshin wrote:
> We have to fight with supervisor concepts: we do not accept
> configuration in start_link/init, because it may change later.
Two thoughts on dynamic supervision and a final thought that leads to a
- Thought 1: Supervision tree declarations
It is possible to write a declarative structure that defines a
supervision tree and a function to read down it, spawning the
appropriate supervisors and workers as it goes along.
Because this is possible it is also possible to make the supervision
tree definition be the dynamic output of another function. There is no
necessity for the parameters for supervision start to be statically
defined as literals -- the input for this could come from anywhere.
(I've experimented with dynamic generation and parsing of the definition
code a good bit, but the uses cases are very narrow in production code
-- a boringly obvious, readable, static definition is the right answer
*almost* all the time. I might make a lib for the "read this supervision
tree declaration and start it up" if there is any interest in it. It
does make reading a new project for the first time pretty easy because
the structure of the project is obvious by glancing only at the tree
definition instead of chasing ideas around the codebase.)
- Thought 2: Dynamic supervision definitions usually suck
It is quite a common experience to find projects in the wild (or
especially in consulting) where I find supervisor code that is dynamic
and therefore not easy to understand at a glance what the final
structure and relationship of the resulting processes will be. It is
also common in such projects for supervision to me more of a "plate"
than a "tree" and lack any true robust recovery capability beyond the
This is nearly always a bad approach.
- Thought 3: What does "dynamic" mean?
When we start a supervisor it starts with a restart strategy and its
child definitions. Until now "dynamic supervision" has meant "start
parameters at start time", but not dynamically updating the supervisor's
overall rules on the fly.
We can dynamically add and remove child definitions and start/stop
children by making requests to a supervisor. Why can we not also check
and update supervisor rules and childspecs on the fly?
The use cases for this would be extremely limited, but it doesn't seem
hard to implement a complete compliment to supervisor:get_childspec/2
(with the exception of trying to change a simple_one_for_one to anything
else or vise versa).
More information about the erlang-questions