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

[Siri Hansen]

Hi Vance,

sorry for the delayed answer. We have had some discussions within our team
and we do find your idea interesting. We do, however, not really like the
idea of setting the limit in the call to supervisor:start_child, but rather
think it should be possible to set such a property on the supervisor or in
the child spec.  The drawback of this, as you say in an earlier mail, is
that it would require changing the supervisor spec - and that is a much
bigger change. We do, however, plan to make the supervisor API a bit more
flexible and by that adding the possibility of introducing new properties.

The timeframe for this is not yet set, and a contribution would of course
help speeding things up :) We already got a patch a good year ago (
http://erlang.org/pipermail/erlang-patches/2012-January/002574.html) but it
was never completed...

/siri


2013/4/11 Vance Shipley <vances@REDACTED>

> On Wed, Apr 10, 2013 at 08:51:11AM -0400, Fred Hebert wrote:
> }  Have you considered using ETS counters, and possibly a monitor process?
> ...
> }  If you're in the kind of position where you need to limit the number of
> }  transactions to avoid falling over, it will *not* reduce the number of
> }  messages sent to the supervisor, and if you start going over the top,
> }  you'll time out no matter what, just because the supervisor won't be
> }  able to keep up with the demand.
>
> Fred,
>
> Your approach is quite valid however it addresses an issue I am not as
> yet considering.  I am concerned not about overload protection but in
> policy enforcement.  The supervisor should have no more than N workers.
> The correct place to address that issue is in the supervisor.  True, I
> could address it otherwise but I propose a small change to support this
> in the OTP implementation.
>
> The alternative solution which my coworkers have historically used is
> long lived pools of processes.  I believe that the Erlang way is to have
> a process with a life cycle matching the transaction's.  It makes me much
> happier to eliminate the pools.
>
> --
>         -Vance
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20130412/c3ca9d4c/attachment.htm>