[erlang-questions] Re: Supervisors as factories *and* registries

[Scott Lystig Fritchie]

This was a thread from last week, sorry I didn't read it sooner.

Jay Nelson <jay@REDACTED> wrote:

jn> Supervisor should have the following goals:
jn> [...]
jn> 3) Minimal functionality and API so that programmer error is less
jn> likely

I just wanted to add something to this point.  An unstated reason for
the minimal 'supervisor' API is that it also needs to be
responsive/fast.  If you have a supervisor that's responsible for a lot
of children, you don't want communication with that supervisor to
timeout while it's simultaneously managing its children.

One way to simulate this is to have gen_server-based workers that each
take multiple seconds to execute their init() callback.  IIRC the
supervisor is blocked waiting for that.  With lots of children and slow
child startup, and then if the supervisor is responsible for doing even
more stuff, then it's possible for the supervisor to fail to start at
all.  Such a failure defeats the purpose of using 'supervisor' behavior.

Ericsson's collective experience in this area greatly exceeds mine, and
even I've been bitten by supervisors failing when asked to do too much.
The 'supervisor' simplicity probably isn't a matter of, "Less is more",
it's more like, "Less is necessary."

Having said that ... there's no reason why you can't roll your own
behaviors.  How many behaviors are part of OTP?  Five?  And OTP has been
around for well over 10 years now?

One of the goals behind OTP behaviors is to foster good code amongst
large development teams.  Open source development certainly qualifies.
If we find more design patterns that others find useful, then they
should be let loose onto the world.

-Scott