<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It seems to me that you were mistaken as the 4 (id) and 4 (serial) in the External Term Format specification (*) indicate the sizes in bytes rather than in bits.<br>
<br>(*) <a href="http://www.erlang.org/doc/apps/erts/erl_ext_dist.html#id87011" target="_blank" style="font-family:arial">http://www.erlang.org/doc/apps/erts/erl_ext_dist.html#id87011</a></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Sep 12, 2013 at 6:22 PM, Michael Truog <span dir="ltr"><<a href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 09/11/2013 09:58 AM, Serge Aleynikov
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default">Presently the PID representation in
external term format is limited to the following:</div>
<div class="gmail_default">
<br>
</div>
<div class="gmail_default"><a href="http://www.erlang.org/doc/apps/erts/erl_ext_dist.html#id87011" target="_blank">http://www.erlang.org/doc/apps/erts/erl_ext_dist.html#id87011</a><br>
</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">
<div class="gmail_default">./erts/emulator/beam/erl_node_container_utils.h:#define
ERTS_MAX_PID_NUMBER ((1 << _PID_NUM_SIZE) -
1)</div>
<div class="gmail_default"><span>./</span><span>erts/emulator/</span><span>beam/erl_term.h:#define
_PID_NUM_SIZE 15</span></div>
<div><br>
</div>
</div>
<div class="gmail_default">ID is limited to 15 bits</div>
<div class="gmail_default">Serial is limited to 3 bits</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">So in total a PID consists of 18
bits, and therefore it seems that the number of pids on any
remote node cannot exceed 2^18 (262144). While it may seem
like a large number, when creating a node in other languages
that implement Erlang distributed transport (e.g. C/C#/Java)
and create/destroy mailboxes, the local pid counter used to
create unique Pids can easily go over that limit. The
work-around is to cache freed local pids and resurrect them
when pid counter wraps around 2^18 boundary.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">This brings the question of whether
that limitation is still necessary in the current version of
distribution. Internally Pids use a wider representation (is
it 28 bits?), so aside for supporting older versions of beam
(which can be worked around through flags in distributed
transport) is there any valid reason not to increase the pid
maximum numbering limit?</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">BTW, as a side note, how is the same
problem addressed in the beam when the pid ID counter reaches
that limit? Does it make it possible that a newly assigned Pid
becomes non-unique? (I.e. if some entity still maintains a
reference to an old Pid that died, and later after the pid ID
counter wrapped around, a new Pid was assigned the same Pid ID
number of a previously dead Pid, then the entity that had the
reference to the old Pid with the same ID, could send a
message to it that would not be valid for the new Pid.)</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">Serge</div>
<div class="gmail_default">
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
erlang-questions mailing list
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
Why wouldn't the Erlang VM be changed to use 4 bits for the Serial
and 4 bits for the Id, so that the sizes match what the External
Term Format allows? Is this change on the Erlang VM roadmap?<br>
<br>
<br>
</div>
</blockquote></div><br></div>