<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Yes, what I meant was:<br>
      Why wouldn't the Erlang VM be changed to use 4 bytes (32 bits) for
      the Serial and 4 bytes (32 bits) for the Id (giving us 46 more
      bits), so that the sizes match what the External Term Format
      allows?  Is this change on the Erlang VM roadmap?<br>
      <br>
      On 09/12/2013 04:05 PM, Serge Aleynikov wrote:<br>
    </div>
    <blockquote
cite="mid:CANt451kYySKYuiJGp0DgF_s+rmSxV5+bQxLx5aqg_BO+Zn7Swg@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=ISO-8859-1">
      <div dir="ltr">
        <div class="gmail_default">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 moz-do-not-send="true"
            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></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 moz-do-not-send="true"
              href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote">
            <div>
              <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 moz-do-not-send="true"
                      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 moz-do-not-send="true" href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<a moz-do-not-send="true" 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>
    </blockquote>
    <br>
  </body>
</html>