ensure_started

[Ulf Wiger]

On Wed, 26 Mar 2003, Chris Pressey wrote:

>I've refined my guideline: in waiting for a reply,
>a) if you monitor the process, always accept a DOWN message as a valid
>reply (as Vlad S. pointed out);
>b) if you link to the process, always accept an EXIT message as a valid
>reply (unless you want your process to die too);
>c) if you don't monitor or link, always use a finite timeout.
>
>To avoid the timeout in the case of c) (just thinking out
>loud here, not suggesting anything) you'd need an atomic
>recieve_or_exit.

I don't think that's enough. The server may receive your
message and then die while processing it, or it may die
while the message is still in the queue.


>Ulf also wrote:
>>However, reg_name ! foo _will_ fail if there is no process
>>registered as 'reg_name'.
>
>However, if we wanted to take this approach for avoiding
>timeouts (again, just thinking out loud), not only would we
>need an atomic recieve_or_unregister_self, we would have a
>need to register processes dynamically, so we'd need to
>either garbage-collect the atom table, or allow processes
>to be named with arbitrary (or at least
>garbage-collectable) terms.  A bit messy, any way you slice
>it.

You still have to have a timeout and (preferably) a monitor.


>I have yet to use monitor; I learned Erlang from "the book"
>and I've been slower to adopt things that aren't mentioned
>in it.  I should definately look into it soon.

Monitors were added because you cannot use links easily in
e.g. a function like gen:call(). The main differences
between link and monitor are:

- monitors are one way. Thus, the other side cannot mess up
  your supervision by unlinking.
- they are stackable, meaning that you will get a distinct
  DOWN message for each call to monitor. Links are not
  stackable; subsequent calls to link/1 are simply ignored,
  but you only need one call to unlink/1 to remove the
  link. This forces you to implement a reference counting
  framework for links if you want to use them for temporary
  supervision.
- Links can be used for automatic cascading exits. Monitors
  can't (you have to explicitly react to the DOWN message
  and exit if you want to do the same with monitors.)
  Another way of putting it: 'EXIT' is a special message
  that will kill a process that's not trapping exits(*)
  while 'DOWN' is a plain message.

My recommendation is: always use monitor to monitor another
process; use links for cascading exit.

/Uffe

(*) {'EXIT',Pid,normal} is not lethal.

-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes