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

[Jachym Holecek]

# Vance Shipley 2013-04-03:
> 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.

This is very easy to do with a custom gen_server, literarily a few lines
of code, for the common case that the "child spec" is known in advance and
fixed, and worker processes are relatively short-lived.  Simulatenously it
gives you a convenient place for some management logic, often handy.

I imagine this (the above constraints) might be your case? Can isolate a
minimal example if desired.

To be clear: by "a few lines of code" I'm referring to a version that does
spawn rate limiting, fault rate limiting and concurrency control. For cases
that need to do more involved regulation a gen_fsm works better, but the
general approach is the same.

Just wondering if it's worth further increasing supervisor(3) complexity.

BTW The same argument and concern also applies to simple_one_for_one, or
at least to its prevalent use cases. But that's already in.

BTW For cases where child processes are spawned at high frequencies I find
it counterproductive to use supervisors -- SASL log gets flooded with what
in practice tends to be pure noise, obscuring any important going ons. One
more small argument for tailor-made solution.

BR,
	-- Jachym