some basic questions

Ulf Wiger etxuwig@REDACTED
Mon Oct 11 09:30:17 CEST 1999


Per, I agree with you.
I'd like to add one piece of information

On Sat, 9 Oct 1999, Per Hedeland wrote:

per>Ulf Wiger wrote:
per>>Well, there is a new monitor() function in OTP R5B, [...]

per>Hm, unless I'm missing something, monitor/2 is "just" a generalized (but
per>so far only applies to pids) and uni-directional version of link/1
per>(which is bi-directional) - plus monitor produces normal messages rather
per>than EXIT signals. And of course link/1 has been around since forever,
per>and has worked across node limits ever since nodes came into existence
per>as far as I know (it predates distributed Erlang).

Yes, but unfortunately, link/1 hasn't been that useful in monitoring
process communication. In fact, the one thing link does very well is
cascading exits (that is, if one process dies, all processes linked to it
will die.)

There are a couple of things "wrong" with link:

- It's two-way, which means that if you link to another process,
  you may cause trouble for that process if "you" die -- typically,
  a server may not have to trap exits, but if clients start 
  linking to it, it may have to in order not to die when they die.

- It's not additive, that is, the runtime system doesn't remember
  how often you called link/1. There will only be at most one link,
  and the first call to unlink/1 removes it. That makes it difficult 
  to have nested calls to link/1.

So basically, there was a need for a monitor() primitive.
And monitor/2 solves the problems above. I believe the reason
why it doesn't work across node limits yet, is that it wasn't obvious
how to implement it efficiently.

The traditional way to achieve safe process dialogs is to use "call"
semantics, guarded with a timeout. It always works, as long as you handle
the problem that the answer arrives just shortly after your timeour
expires.

The problem in real-time systems is that even if the server process dies
before reading the message, you must wait for the length of the timeout to
find out that something went wrong. Using monitor/1, you will find out
immediately.

/Uffe

Ulf Wiger, Chief Designer AXD 301      <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuvägen 9, Älvsjö                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44




More information about the erlang-questions mailing list