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

[Vance Shipley]

On Wed, Apr 03, 2013 at 08:29:05AM -0400, Fred Hebert wrote:
}  Is the limit counted based on living children, or on the number of
}  children specifications currently active?
  
Not living, just child specifications.  Checking for living children
is too heavy weight here.  The supervisor had been enhanced to use 
dict() or sets() to store dynamic children with the addition of
count_children/1.  So checking the size of the child list is O(1).
If you need to know how many are alive count_children/1 can be used.

}  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 only used '0' internally, the API insists on a pos_integer().  I did
think the OTP team might want the internal interface to be backward
compatibile so I was expecting some change there.

}  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.
  
Yes, you are right about that.  Noted.

}  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.

Not at all!  My sore spot involves high frequency spawning of short lived
processes and I cannot afford the sort of overheads you are suggesting.
My solution is quite low overhead, the intent is to have the lowest possible.

}  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?

To make the supervisor do it would require changing the SupSpec which
isn't going to happen.  Also it is more flexible to set a limit each
time as it may change over time.

-- 
	-Vance