<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
You have made a modification which goes against fundamental principle
(asynchronous message passing and transparency of local remote
processes) of the process communication mechanism. We, Joe, Mike and I,
probably never wrote down the priinciples but they were there. Although
sometimes we aourselves weren't completely consistent either
(registered processes).<br>
<br>
Robert<br>
<br>
Raimo Niskanen wrote:
<blockquote cite="midlq4q723xgr.fsf@erix.ericsson.se" type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:robert.virding@telia.com">robert.virding@telia.com</a> (Robert Virding) writes:
I have dug into the archives...
This was introduced fairly recently, in R9B, in conjunction
with the rewrite for more than 255 remote nodes.
We will look into this and decide what to do.
</pre>
<blockquote type="cite">
<pre wrap="">No, no, no it should definitely NOT return error(noproc).
The reason is that the whole process communication mechanism,
including links, was originally designed to be asynchronous on the
sending side. Sending a message is asychronous, ou don't wait in the
send to find out if it arrived. Link/1 works the same way. The call
does not wait until the link is set up but just sends the request and
continues. If the process does not exist the caller is notified by a
noproc exit signal from the non-existent process (yes I know but from
who else could it receive it?).
The important point is that in bothe cases the call is
asynchronous. This also means, mostly importantly, that both calls
function the same way irrespective of whether the other process is
local or remote. This was also an original goal.
If this has significantly changed since then then someone has missed
the original intentions.
Robert
Francesco Cesarini (Erlang Training & Consulting) wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">It is all there, really. Only it was written before exceptions
were invented as a concept in Erlang, uses the term
"exit signal" in a confusing way and lies about "does not fail".
Ok, it is maybe dead wrong, but the intention was right.
So, what happens is:
link(Pid) -> true if Pid exists or the caller has
process_flag(trap_exit, true).
error(noproc) otherwise
The enclosing catch evaluates to {'EXIT',{noproc,Stackdump}}
for error(noproc). Weird behaviour, in my opinion..
</pre>
</blockquote>
<pre wrap="">
Exactly my point. Would it not be better to return error(noproc)
even if trapping exits instead of exit(Pid, Reason)?
Francesco
--
<a class="moz-txt-link-freetext" href="http://www.erlang-consulting.com">http://www.erlang-consulting.com</a>
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>