[erlang-questions] Why have a supervisor behaviour?

Roger Lipscombe roger@REDACTED
Fri May 22 17:02:43 CEST 2015

On 22 May 2015 at 15:19, Fred Hebert <mononcqc@REDACTED> wrote:
> On 05/22, Roger Lipscombe wrote:
>> It turns out that I probably don't need a supervisor at all, then.
> Ah that's interesting. To reason about this, one question to ask is: what is
> it that your system guarantees to its subsequent processes. So if you have
> some form of front-end or client handling the order of spawning and
> restarting a VM (who do you do it on behalf of?), there's likely a
> restricted set of operations you provide, right?

- Find (or start) a VM by ID.
- Stop a VM, either by ID or by sending it a message.
- Send a message to a VM. Some of these are gen_server:call, because
either we need back-pressure, or we need a response; some are
gen_server:cast (or Pid ! foo), because we don't.

> To really help figure this out, simply ask "Can my system still run if X is
> not there?"

In this case, yes. If we get into a situation where we're consistently
failing to start the squirrel VM, or if they're _all_ consistently
failing, we'll spot that through metrics or another form of alerting.

> Does this make sense?

Yes. Absolutely. I need the squirrel_vm_manager (to give it a name) to
be up, so that I can find_or_start and stop the VMs. Whether a
particular VM is up or not is not a problem for *my* application as a


More information about the erlang-questions mailing list