question about supervisors

Gaspar Chilingarov <>
Wed Jul 27 13:35:14 CEST 2005

Francesco Cesarini (Erlang Training & Consulting) wrote:
> Yes, assuming the supervisor itself does not crash and is restarted by 
> its supervisor.

yeah documentation says the following:

........If more than MaxR number of restarts occur in the last MaxT 
seconds, then the supervisor terminates all the child processes and then 
itself. When the supervisor terminates, then the next higher level 
supervisor takes some action. It either restarts the terminated 
supervisor, or terminates itself.  .......

so , usually I can think that things gone very bad, if supervisor died 
and I can terminate another processes too.

> If you only have one instance of that worker / supervisor, it is common 
> to register them with a static name, avoiding the need of the pid.
> Francesco

It was discussed a few time ago - in a "Meyer, OO and concurrency" topic
I'm repeating this question just to clarify this issue :)

With functional programming you supply all the data required to
a function, instead of global variables you use arguments.  The
same applies here, start the clients with the pid of the server.

I generally use registered processes if the client and server are
in separate applications.  Within the same application it is usually
easy enough to initialize the client properly so that it knows where
it's server is.  Another trick I use is to inspect the supervisors.

I can see one possible quite useful aspect of applying such technique --
writing test for such code should be easier, that registering bunch of 
processes which proper names.

Another Question: how do supervisor handles large number of processes ?

I have about 2^13 processes, which sometimes - on timeouts or on data 
arrival do processing and time to time save their state to dets.
Also I have manager which maps FooID* to worker PID, but does not 
restart workers - it's ok for worker to die or lose some little amount 
of data, if no alive worker for some FooID found, worker is started, it 
reads state from dets and continues to process arriving data.

Usually I have at least one message per minute for each worker process.

In case if manager process dies (for some reason) -- which is the better 
  way ? kill all worker processes and let them spawn again? or each 
worker process should understand, that manager died, find restarted 
manager and register as worker for FooID -- because it re

FooID -- some key to identify data :)

Gaspar Chilingarov
System Administrator

t +37491 419763 (mob)
t +37410 240399 (office)
i 63174784

More information about the erlang-questions mailing list