[erlang-questions] Re: Supervisors as factories *and* registries
Tue Mar 23 18:46:32 CET 2010
On Tue, Mar 23, 2010 at 9:57 AM, Jay Nelson <> 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
> 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.
More information about the erlang-questions