[erlang-patches] Add supervisor:start_child/3 to limit the number of children

[Fred Hebert]

Is the limit counted based on living children, or on the number of
children specifications currently active?

I am also not a fan of overloading the number '0' to mean "no limit"
instead of "0 children allowed". We have atoms, and we should make use
of them. Send in '{limited, N}' or 'unlimited', or 'infinity', or any
other token value that is 100% explicit about the intent instead of just
a '0' that people have to figure out what it means according to context
rather than what it explicitly says.

I think it would also be a good idea to check the type to be an integer
greater than 0 (instead of just greater than 0, like a list or a tuple
would be) at the call site rather than way too late, within the
supervisor.

If I were using limits like that to add a boundary to a pool, I'd worry
about how the tracking happens. It seems to me that doing it all in the
supervisor is surprisingly inefficient compared to having, say, a fixed
pool, or a gen_server that monitors workers and starts them for you so
the counter is implicit and direct rather than linear based on the
number of children, and repeated on every single call. Just how often
are you calling for new children to be added to the pool, and why does
it happen so often as to be a problem? Does it happen frequently enough
to be a problem, but infrequently enough for the supervisor to be able
to do it without degrading its service?

I don't have specific opinions for or against the feature itself and
would defer to the OTP committee to judge its worth -- just gave your
code a quick review :)

Regards,
Fred.

On 04/03, Vance Shipley wrote:
> git fetch git://github.com/vances/otp.git supervisor_child_limit
> 
> https://github.com/vances/otp/commit/04f94f86e5495f29b61654d7f744ae3eeaca9297
> 
> With the addition of a Limit argument in start_child/3 the supervisor
> will either start a child or return {error,child_limit}.
> 
> A supervisor behaviour process may have dynamically added children
> started by other processes.  The count of the number of children
> could be retrieved from the process with count_children/1 before
> starting another with start_child/2 if a maximum number of children
> is to be maintained.  This introduces an overhead of a round trip
> message and the possibility of a race condition.
> 
> This is quite useful where a fixed size pool of processes might
> otherwise be used and is suitable for cases where child workers are
> started with high frequency.
> 
> -- 
> 	-Vance
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches