Re: Supervisor and configuration update — how to do it?
Wed May 20 09:47:33 CEST 2020
On 5/19/20 10:36 PM, Max Lapshin wrote:
> Our flussonic has big amount of code related to smooth configuration
> update. Almost all configuration parameters can be changed on fly: it
> is very important, because we handle big amounts of video traffic. It
> is very bad to leave 20 000 people without video if you want to
> reconfigure single channel.
> We have to fight with supervisor concepts: we do not accept
> configuration in start_link/init, because it may change later.
I prefer putting configuration in start_link/init and changing it with a
message. That keeps the approach functional, pursuing referential
transparency, making sure the update of the configuration info is not
error-prone because the sequence for the update gets well represented in
a sequence of functions that are called (easy to test, easy to add
asserts to, easy to reason about and make assumptions about). I am
assuming you don't use the process dictionary. Things are normally not
completely referentially transparent due to catching exceptions and
messages getting received, but often that processing is isolated in
function calls for that purpose.
I understand the tendency to pursue ets, mnesia, persistent_term or a
global data store for (transient read-write) configuration, because that
approach seems easy with mutable data and time is spent trying to ignore
the data inconsistency problems that occur as things change. Arguing
for global data is similar to arguing about the benefits of global
variables and imperative programming, so often people coming from an
imperative programming background will feel compelled to find a way to
use global data to solve problems. Its best to resist this temptation in
a language that supports functional programming.
More information about the erlang-questions