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

[Garrett Smith]

On Tue, Mar 23, 2010 at 9:57 AM, Jay Nelson <jay@REDACTED> wrote:
> Anthony Shipman wrote:
>
>> But if the child crashes and restarts the pid will be out of date.
>
> That was why I had a caveat about restarts, etc.  In the general case, Ulf's
> gproc gives you global access to find processes.  If you want to keep
> something local or of limited propagation, you have to build extra machinery
> to monitor the processes:
>
> 1) A gen_server to store the ets table (or gb_trees or dict since you now
> have a pid container for any data structure)
>
> 2) A supervisor for the new gen_server.  It could be the same supervisor for
> the child processes, with the gen_server started first and a rest_for_one
> policy...
>
> 3) But if it is a simple_one_for_one supervisor now, you need a parent
> supervisor with rest_for_one and then start the gen_server first and the
> child supervisor second.
>
> 4) Inside the gen_server, you can cast new Child Pids, monitor them and
> remove them from the gen_server state when the go 'DOWN'
>
> This seems like a lot of machinery, so I can see the desire to want a State
> internal to the supervisor, but this approach actual uses a "separation of
> concerns" method of isolating each of the new features and allows you to
> monitor and manage them independently.

Yes, though this machinery is my motivation for using supervisors to
handle the process life cycle house keeping in the first place.

> Supervisor is a well established and reliable implementation that is kept
> simple but allows composition of hierarchies.  This follows the functional
> way of compositional design.  I do believe it may be time to start talking
> about a family of supervisors which have different strategies for managing
> their children.  Right now there is one supervisor with a flag mechanism for
> management style.  Maybe now the experience with non-telco problem areas can
> advise the development of a larger family of process supervision models.

I'm curious why this doesn't come up more often :)

> The second point I wanted to make was to show how a functional design is
> extended (as opposed to an object-oriented design).  An exported function is
> an entry point that can be extended or augmented (in this case it would be
> called a decorator pattern in OO).  A new function is exported which calls
> the previous function and does some additional work to make it look like a
> new implementation.
>
> So the existing model allows both API augmentation, and functional
> composition of the hierarchy to add functionality.  It is possible, although
> maybe tedious for complicated situations, to achieve the goal with the
> existing structure.  But I think a discussion of alternative supervision
> approaches may lead to an expanded view  of managing processes which OTP
> could accommodate.

Usability (including initial development, transparency of design, and
maintainability) is of high importance to me. I *really* try to avoid
trap_exit, because it seems a slippery slope into process management
spaghetti code. But maybe I'm just a coward :\

I still wonder though why there isn't a supervisor variant that lets
you manage custom state the way gen_server and gen_fsm do. I'm
assuming it's to avoid complicating an otherwise very simple module.
But you'd get some pretty useful stuff:

- Ability to index processes (this is not as general purpose as gproc,
but it could be used to solve similar problems)
- Custom start and restart behavior
- Other housekeeping associated with process life cycle management

It seems that a handful of behavior callbacks would enable this, but I
may be over simplifying things.

Garrett