Re: Supervisor and configuration update — how to do it?

[zxq9]

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 
question:

- 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 
first layer.

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).

   supervisor:get_childspec/2
   supervisor:set_childspec/3
   supervisor:get_restart_strategy/1
   supervisor:set_restart_strategy/2

Thoughts?

-Craig