[erlang-questions] Was Re: Bug ?! now Erlang comment (LONG LONG)

[Ulf Wiger]

Den 2006-10-22 23:20:36 skrev Robert Virding <robert.virding@REDACTED>:

> With links there are 3 parameters which describe the link:
> signal/message, single/multiple and uni-/bidirectional. With link/1 you
> get a signal-single-bidirectional connection berween the processes and
> with monitor/1 you get a message-multiple-unidirectional connection. You
> could of course have any combination of these parameters that you need.
>
> My main complaint is that instead of generalising the basic link
> construct - connecting two processes to exchange termination information
> - it is defined as something different. So instead of ONE versatile
> basic construction you now have TWO restricted ones neither solving the
> whole problem.


If you have a suggestion of how this could be accomplished nicely
in one function, I'm sure there is still time to consider its
introduction. I gather you wouldn't call it monitor/2 and demonitor/1,
so the introduction of monitor shouldn't be much in the way. ;-)
I agree that it's a bit unfortunate to have two different
specialized constructs, at least on principle.

The problem that arises when you don't pick the right generic
construct from the start is that it does get more difficult
to fix it later. Now, people are used to links being signal-single-
bidirectional, and would be confused if they started acting
differently. Monitors have the advantage of NOT being links;
therefore, they can behave differently without causing consternation
among the users.

Years ago, there was a suggestion to make registered send act just
like normal send (i.e. not crash if the name didn't exist). While
this was logical and consistent, and therefore probably an improvement,
one practical effect was that some code that would previously crash
in certain situations, would now hang forever. So, elegance had to
give way to backward compatibility.

Actually, monitors were born in the wake of this.

BR,
Ulf W
-- 
Ulf Wiger