Supervisors as factories *and* registries
Tue Mar 23 16:57:29 CET 2010
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.
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.
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.
More information about the erlang-questions