Hi Viktor :) > I support this EEP. :-)
Glad to hear :) > It has been argued before that supervision trees are for fault-tolerance > of bugs, not network/external errors. But why not enable the use of > supervision subtrees for external faults too? Yes, I understand both sides of the argument, but yeah, why not? :) The real problem we had was to figure out how to delay it right. Dragging out the time between crashes and restarts opens up some new scenarios and corner cases, especially in the sibling-terminating strategies. > If we add delays, then how about exponential backoff? e.g. doubling the > delay for each failed restart attempt. Is it worth considering too? It > has been suggested before and it's common for network re-attempts. We considered but decided against it, for now at least. Simple as it sounds on the surface, there is actually quite some complexity involved. We think that providing delays alone is already a big step forward, and paves the way to future improvements like incremental delays. > Just forbid the existence of the key restart_delay when restart type is > temporary. We considered this also, but it feels a bit wrong =^^= I mean, it is always allowed to have any meaningless key in the map, they are just ignored. Other keys (like significant) are allowed to appear as long as their values don't clash with other options. Forbidding some keys to appear based on the values of other keys, that would be new and unique. Regards, Maria _______________________________________________ eeps mailing list [email protected] http://erlang.org/mailman/listinfo/eeps
