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

[Siri Hansen]

Hi Vance,

I'm happy to announce that in OTP-18, the supervisor API will be improved
to allow supervisor flags and childspecs declared as maps (similar to
http://erlang.org/pipermail/erlang-patches/2012-January/002574.html, except
maps are used instead of proplists). This will allow for additions to these
data structures. We now wonder if the functionality handled in the current
thread is still wanted, and if so if the patch should be rewritten to use
the new API?

Regards
/siri



2013-04-12 18:53 GMT+02:00 Siri Hansen <erlangsiri@REDACTED>:

> 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/20150115/ffedfc35/attachment.htm>