[erlang-questions] pid representation in external term format

[Serge Aleynikov]

Presently the PID representation in external term format is limited to the
following:

http://www.erlang.org/doc/apps/erts/erl_ext_dist.html#id87011

./erts/emulator/beam/erl_node_container_utils.h:#define ERTS_MAX_PID_NUMBER
          ((1 << _PID_NUM_SIZE) - 1)
./erts/emulator/beam/erl_term.h:#define _PID_NUM_SIZE                 15

ID is limited to 15 bits
Serial is limited to 3 bits

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.

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?

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.)

Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130911/96b107c5/attachment.htm>