[erlang-patches] allow use of proplists in supervisor start specs

[Ulf Wiger]

Sounds good.

My personal preference is MaxR = 3, MaxT = 10, which is slightly more aggressive.

For one thing, if you have, say, 3 levels - top supervisor, a few supervisors underneath, and some workers, and they all have MaxR = 10, you will suffer 1000 restarts before a complete escalation. With MaxR=3, you will have 27, which would be excessive, but not ridiculous. Granted, you should always think through your restart limits for deeper trees.

BR,
Ulf W

On 3 Jan 2012, at 22:11, Richard Carlsson wrote:

> The formats of the supervisor flags (the 3-tuple {one_for_one, Restarts, Time}) and the child specifications (6-tuples {name, etc., etc.}) are annoyingly hard both to read and write. This patch makes it possible to pass lists of options instead, and sets useful defaults for most fields. This also opens for the possibility to add more flags both to supervisors and children in the future.
> 
>  git fetch git://github.com/richcarl/otp.git proplist-child-spec
> 
> For example:
> 
>  init()
>     SupFlags = [{period,10}],
>     Child = [{name, foo}, {start, {M,F,A}}]
>     {ok, {SupFlags, [Child]}}.
> 
> This gets you a one-for-one supervisor with a particular restart time period, and a single child with default behaviour. The name and start options are required.
> 
> The supervisor flag defaults are:
> 
>    strategy = one_for_one
>    intensity = 10
>    period = 30
> 
> I.e., one-for-one supervision and at most 10 restarts in the last 30 seconds. This restart frequency seems like a useful default; let me know if you think some other numbers would be significantly better.
> 
> The child spec defaults are:
>    restart_type = permanent
>    shutdown = 2000
>    child_type = worker
>    modules = [M], where M is the module in the start MFA
> 
> Finally, there is a new function supervisor:get_childspec(Sup, Child) which can be used to get the full child specification (as a list) needed to restart the same child or another child like it.
> 
> Note that the documentation has not been updated as part of this patch.
> 
>  /Richard
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches