Supervisors - why not have an option to pass an anonymous. function / function capture too?

Chat & Discussions Proposals: Ideas
,
1

So the other day I was rearranging the supervisor hierarchy of our product and I had a thought. In addition to creating a child spec with hard-coded values (restart strategy, interval etc) why not have an option to pass an anonymous. function / function capture too. This would take the reason for the crash along with the state of prior crashes as arguments and can be used to handle special cases.

The function could override the provided default restart options, or perform additional tasks / permit finer-grained control. For example with one_for_all configuration one could alert peer processes prior to restarting. I realize that some of this could be done via another process that called Process.monitor/1, but that would handle the crash in parallel with the supervisor. You would also need to ensure the provided function didn’t crash or block the supervisor.

e.g.

sup_fun = 
   fn {%RuntimeError{message: "ooops"}, _}, %{current_restarts: restarts, ....} -> 
         # Logic for oops
        {:restart, :one_for_one}

      {%RuntimeError{message: "big ooops"}, _}, %{current_restarts: restarts, ....} ->
         # Logic for big oops
        {:restart, :one_for_all}

       _, _ -> :default ## Do the provisioned actions
end

....

% My Erlang is a bit rusty
handle_info({'EXIT', Pid, Reason}, #state{handler_fun = Fun} = State) ->
  SupPid = self()
  FunPid = spawn(fun() -> SupPid ! {actions, self(), Fun(Reason, State)} end)
  receive
      {actions, FunPid, Actions} -> 
         handle_crash(Pid, Reason, Actions, State)
  after
    2000 -> 
         handle_crash(Pid, Reason, default, State)    
  end

I guess there’s some complexity since Elixir leverages the OTP supervisor. Maybe this is more of an Erlang question?

2

I suspect this is related to hot code loading, which was important to Erlang/OTP development even though the Elixir community mostly avoids it. Anonymous function references can become invalid when the module they were defined in is updated in the BEAM.

1 Like
3

People fear what they cannot understand. Once a “phoenix” framework comes for hot-code reloading this will become the new hot topic. I think we both lack abstraction and education on how to use it yet, but at the same time we have some infrastructure in place to facilitate the adoption.

1 Like
4

I hope you’re right. I enjoyed using it for my first 3 years of working in Elixir. (“hot topic” I see what you did there :smirk: )

3 Likes
5

Valid point. The other option would be to provide M, F. A.

6

I think that it will be a hot topic when we start to get Elixir people talking about self-hosting and things like that, which is becoming a hot topic in some other communities.

2 Likes