[erlang-questions] Why have a supervisor behaviour?

Karolis Petrauskas <>
Thu May 21 19:08:38 CEST 2015


Another reason for supervisor to be a behaviour is the code upgrades.
The init/1 function is called on process startup and on code upgrades.

Karolis

On Thu, May 21, 2015 at 6:58 PM, Jesper Louis Andersen
<> wrote:
>
> On Thu, May 21, 2015 at 5:00 PM, Roger Lipscombe <>
> wrote:
>>
>> I need delayed _restart_. Is this what Jesper refers to when he talks
>> about "a delay_manager"? Such that init queries that and then
>> might/might not delay?
>
>
> %% The delay manager decouples delay policy from a worker by tracking delays
> in one place.
> %% As such, it has global knowledge and can opt to delay registered
> processes more or less
> %% depending on current load.
> -module(delay_mgr).
> -behaviour(gen_server).
>
> [..]
>
> %% Call this from a newly started worker, but not in it's init/1 callback
> since that blocks the supervisor
> %% Send the process itself a message in init/1 and do it in that state.
> delay(Reg) ->
>     gen_server:call(?MODULE, {delay, Reg}, infinity).
>
> [..]
>
> handle_call({delay, Reg}, From, #state { conf = Conf }) ->
>     Delay = maps:get(Reg, Conf),
>     erlang:send_after(Delay, self(), {go, From}),
>     {noreply, State};
>
> handle_info({go, Reg}, State) ->
>     gen_server:reply(From, ok),
>     {noreply, State};
>
> [..]
>
> This is static skeleton, but:
>
> * Add monitoring of delayed processes. Increase the delay for processes that
> respawn too often
> * Decay delays for processes which operates as they should
> * Add metrics and stats
>
> --
> J.
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list