Supervisors as factories *and* registries

[Jay Nelson]

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.

jay