<div dir="ltr"><div>I think most of the time the isolation is, as you say, exactly what one wants.<br><br>The supervisor is great at allowing you to structure a supervision tree (supervisors supervising other supervisors), and great at letting you define appropriate behaviour for a set of related / interacting / interoperating / dependent processes (by way of the different restart strategies), but in both these cases the number of children is fixed.<br><br>Supervisor is also great for many simple_one_for_one cases where the number of childen is dynamic, but the capability for being able to set ideal (at least ideologically ideal) restart intensity is weakened when one doesn't know how many children there will be, and when the other conditions from my original email are met I'm stuck with a real compromise (fine if not too many children crash) or supervising the children another way.<br><br>Where the children are not homogeneous they should probably be split into 2 simple_one_to_one supervisors supervised by another supervisor with a strategy appropriate to the relationship of the 2 dynamic sets of children, so then the supervisor as it is MAY be optimal. Where the criticality is not spread (i.e. 10 children has similar over all value in terms of service provision as 100 children) then another solution may be appropriate (like less variation in numbers of children probably).<br><br>It wouldn't be terribly difficult to write a module to supervise precisely as I want, but since supervisor would do what I wanted with the proposed modification I considered it worth gauging interest in the addition. No one as yet seems greatly troubled by the absence of the feature though I must say.<br></div><div><br></div>Michael.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 2:01 PM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015年10月20日 火曜日 12:33:34 Michael Wright wrote:<br>
> Hi Torben,<br>
><br>
> I did wonder about this as a solution, but I'm not terribly keen.<br>
><br>
> Take the case of 10 sup_10 supervisors with a restart intensity of 10, each<br>
> with 10 children. If there are 11 child deaths for children concentrated on<br>
> one of those supervisors, it will trigger a sup_10 restart, but if the 11<br>
> children that die are distributed across 2 or more sup_10 supervisors, it<br>
> won't... The sup_10 restart probably isn't a problem of course, but the<br>
> number of total deaths in a period of time that will cause a sup_sup to<br>
> restart is now variable, depending on exactly which of the children across<br>
> the sup_10 supervisors die.<br>
><br>
> In fact, in this situation, 11 child deaths could cause a sup_10 death, or<br>
> 100 child deaths could just about cause no sup_10 to die.<br>
<br>
</span>With your initial post I thought "hrm, that is sort of odd that it isn't dynamically configurable" but the only scenarios I could think of off-hand for actual systems I would maybe actually use this were ones where I want precisely the sort of isolation you view as problematic.<br>
<br>
As it stands, Torben's suggestion where a sup_sup can spawn dynamically configurable supervisors seems ideal -- especially considering that I could retire an existing sup (with the "wrong" configuration) and direct all new child creation to the new one (with the "right" configuration) -- and, hot updates aside, probably smoothly transition a running process' state to a new process under the new supervisor. There could easily be edge cases where that wouldn't work, but the general case seems straightforward.<br>
<br>
It would be nice to abstract this all away for the general case, of course, and that doesn't seem to require making any adjustments to OTP.<br>
<br>
But I lack imagination. In what case would this not work?<br>
<br>
-Craig<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>