Linking to/from a gen_server?

[Shawn Pearce]

Ulf Wiger <etxuwig@REDACTED> wrote:
> If you want a response back, use call(). It is just
> confusing to emulate calls with casts. The server can return
> {noreply,S'} if it's not possible to respond immediately,
> and then use gen_server:reply/2 later. Since
> gen_server:reply/2 uses the pid of the caller, it is no big
> disaster if you're not using monitors, and the client died
> - the reply message will go into the bit bucket.

Yeah, I figured it would be a big mess trying to emulate call with
cast, so I really wanted to avoid that.  :)

> The big thing that link() can do and monitor() can't, is
> cascading exits. Personally, I try as much as possible to
> use lots of processes and not trap exits unless I absolutely
> have to. This way, I can split a problem into as many
> processes as the problem calls for (but not more than
> that!), tie them together with links and rely on cascading
> exits to clean up if there's a problem.
> 
> For monitoring the well-being of another process, I always
> use monitor().

That's good to know Ulf.  Currently its pretty much what I am
doing.  The monitor is to know when the process exits so I can
garbage collect data my server has stored about the process,
without requring that the process stay linked.

Meanwhile, I'm using link within the OTP supervision tree
to do cascading exits and proper cleanup.

Excellent.

This thread only got started because I had forgetten about
monitor, but after reading the doc page, its exactly what
I wanted.

-- 
Shawn.

  Rebellion lay in his way, and he found it.
  		-- William Shakespeare, "Henry IV"