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