<div dir="ltr">Can anyone shed any light on this??<div class="gmail_extra"><br><div class="gmail_quote">On 14 January 2015 at 10:57, Alexander V Vershilov <span dir="ltr"><<a href="mailto:alexander.vershilov@gmail.com" target="_blank">alexander.vershilov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Hello.<br>
<br>
I want to understand the reasons for the current semantics<br>
for saving remote processes in local registry.<br>
<br>
According to the specification for register function [1] it's<br>
impossible to save remote process in local registry:<br>
<br>
    Failure: badarg if PidOrPort is not an existing,<br>
    local process or port, if RegName is already in use,<br>
    if the process or port is already registered (already has a name),<br>
    or if RegName is the atom undefined.<br>
<br>
As a result it's not possible to construct expression Name ! Message,<br>
where Name is evaluated to a atom stored in registry that points<br>
to the remote process.<br>
<br>
Another approach is described in unified semantics paper (Section 2.3)<br>
<br>
    However, for uniformity, in this semantics names can be registered<br>
    for remote processes (i.e., register(name,pid) does not fail if pid<br>
    is a remote process), and registering a local process at a remote<br>
    node is supported too (using the operation register(node,name,pid)).<br>
    As a consequence, when a message is sent to a remote node using the syntax<br>
    {atom,node}!msg there is no guarantee that the process that should<br>
receive the mes-<br>
    sage is located at node; thus it may be necessary to relay the message<br>
    to a process on yet another node<br>
<br>
So I have two questions:<br>
<br>
1. Were there any technical reasons for forbidding remote pids in local<br>
    registry as we have in current erlang, or it's a historical reasons?<br>
2. If there are technical reasons for that, then why uniformed specification<br>
    introduces such behaviour, or it provides some mechanisms to solve<br>
    those problems?<br>
<br>
One can argue that the reason is monitoring, and case when we are sending<br>
to the remote process from registry that already dead, but I don't see any<br>
difference with sending to remote Pid that already died, semantics of all<br>
the functions and guarantees are the same.<br>
<br>
Thanks<br>
<br>
[1] <a href="http://www.erlang.org/doc/man/erlang.html#register-2" target="_blank">http://www.erlang.org/doc/man/erlang.html#register-2</a><br>
[2] <a href="http://happy-testing.com/hans/papers/EW2010-UnifiedSemantics.pdf" target="_blank">http://happy-testing.com/hans/papers/EW2010-UnifiedSemantics.pdf</a><br>
<br>
--<br>
Alexander<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div>