nhpip

nhpip

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?

Showing Posts 1 to 5

gregvaughn

gregvaughn

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.

D4no0

D4no0

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.

gregvaughn

gregvaughn

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: )

nhpip

nhpip OP

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

marciol

marciol

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.

— All posts loaded —

Where Next? Top

Trending in Proposals: Ideas Top

woylie
We are seeing a lot of warning logs like this: navigate event to "https://someurl" failed because you are redirecting across live_sessio...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews