[erlang-questions] Why have a supervisor behaviour?

[Roger Lipscombe]

On 21 May 2015 at 21:32, Fred Hebert <mononcqc@REDACTED> wrote:
> [...a bunch of useful stuff, but most importantly this next bit...]
> My position is that this isn't a problem with supervisors' interface, but in
> how they are being use and what they mean for your system. I know this is
> not the most helpful response, but oh well.

It turns out that I probably don't need a supervisor at all, then.

Currently I have:

- A supervisor, which supervises:
- A collection of host processes, each of which owns:
- An instance of a Squirrel VM [1] implemented in a C++ NIF.
- When the Squirrel VM wishes to communicate with its host process, it
sends it a message.
- For some of those messages (divide by zero exception, syntax error,
etc.), my host process responds via
  handle_info({exception, Whatever}, State) -> {stop, {shutdown,
Whatever}, State}.
- This causes the supervisor to restart the host, which fires up a
fresh instance of the Squirrel VM.

Because the Squirrel VM is running arbitrary code, it can get itself
into a state where that code constantly crashes, so the host kills
itself, and the supervisor restarts it constantly. My existing custom
supervisor doesn't handle restart intensity, for precisely this
reason. If this happens really quickly, it can lead to bad effects
downstream (log spamming, etc.). Hence the business requirement to
delay the restart to give the rest of the system a breather.

It seems, however, that I *don't* really want a supervisor to handle
restarting the Squirrel VM; it looks like the host should do it, and I
might be able to remove my custom supervisor in favour of a standard
'simple_one_for_one' supervisor to handle crashes in the host process.
Not sure about that last -- I don't want one process hitting max
restart intensity to bring down the other host processes.

[1] http://www.squirrel-lang.org/