<div dir="ltr"><div><div>Does anyone have any interest, approval or disapproval in respect of the idea of adding capability to update the restart intensity of a supervisor after start?<br><br></div><div>Currently the only way to change it after start is by way of a release change.<br></div><div><br></div><div>My reason for the proposal is to optimise the case of a simple_one_to_one supervisor where:<br><br>    1. The likely number of children could vary a lot (perhaps by orders of magnitude).<br>    2. The children are <span class="">homogeneous and the criticality of the service they collectively provide is shared across all of them.<br>    3. T</span>he probability of abnormal termination of any one child is relatively constant (not lessened or known or expected to be lessened by more children being spawned).<br><br></div><div>So for the case of a simple_one_for_one supervisor with 10 children, a restart intensity 10 might be appropriate, but for the same supervisor with 10,000 children it might need to be 1,000, or 10,000.<br></div><div><br></div><div>In some cases the likely maximum number of children might be known at supervisor start time, but not always, and even then if it varies a lot it probably doesn't help.</div><div><br></div><div>I can't be certain how in demand this feature would be, but I've realised I've needed it before, and compromised by setting the restart intensity high to avoid unnecessary tear down of software infrastructure. It's obviously not ideal though as it could lead to outage or service degradation while a relatively small number of children churn their way to an inappropriately large restart intensity.<br><br></div>One could have a dynamic intensity value, {ch_multiple, N} say, making it N times the number of children, but I slightly worry someone will later want {sqrt_ch_mul_ln_moonphase, U, G, H} and then one may as well allow {M, F, A} or add a new callback. However, really I think an API call is probably the most sensible way forward:<br><br></div><div>    supervisor:update_supflags/3    (SupRef, intensity | period, NewValue)<br><br></div><div>I prefer this to passing a map since the above is more explicit that not all the supflags are alterable.<br></div><div><br></div><div>An API call is simple and low impact, and the only disadvantage is it offers 
to do nothing clever, making the callback module perform all the 
management, even if it means calling it every time a new child is spawned.</div><div><br></div>Michael.<br><br></div>