Format of Pids
Thu Jun 5 11:00:11 CEST 2003
erl_interface and ei are currently being cleaned up, but this wont be
finished until (hopefully) R10B.
Vance Shipley wrote:
> Thank you very much for your definitive response!
> On Tue, Jun 03, 2003 at 02:51:34PM +0200, Rickard Green wrote:
> } Creation is an integer which identifies "the creation of a node".
> } Creation is incremented when a node is restarted. Currently creation
> } is a 2-bit unsigned integer. 0 is special and means something like:
> } actual creation used right now. Creation isn't shown when a pid is
> } printed.
> That raises a few questions. In ei (erl_interface) creation is a short.
> I have been setting creation with get_pid(). Since 29607 isn't going
> to fit in the 2-bit unsigned integer used for creation in the VM I
> wonder whether any of this is useful.
> The documentation, in describing ei_connect_init(), has this to say
> of creation:
> "creation identifies a specific instance of a C node. It can
> help prevent the node from receiving messages sent to an
> earlier process with the same registered name."
> This suggests that the creation will be included in the cnode's pid
> sent to the VM so that if it replies to that received pid and the
> nessage is received by a new instance of the cnode we will recognize
> that the destination pid is not ours. If this is the case how is
> the short used in for creation in the cnode mapped to the 2-bit
> unsigned integer used in the VM?
This is a bug.
My guess (before I looked in the code) was that ei_connect_init()
converted the creation passed to it into a valid creation and then
stored it. My guess was wrong, though, it just stores the creation it
has been passed as it is.
When a pid, port or ref is encoded into external format, all creation
bits except for the 2 least significant are dropped. This means that
an ei_encode_pid() followed by an ei_decode_pid() on ei_self() will
in most cases produce a pid not equal to ei_self().
> I also missed this in the documentation:
> "A C node acting as a server will be assigned a creation
> number when it calls erl_publish() or erl_xpublish()."
> I don't see this happening. At least it isn't overwriting the
> creation I set (e.g. 29607).
This is a documentation bug. erl_publish() intentionally drops the
creation it receives from epmd (a design flaw in my opinion).
> } > For instance if I want to quickly test if a Pid
> } > exists I could do if(pid->serial). But is
> } > that right or is num the right field to check?
> } > Or do I really have to compare the whole
> } > structure?
> } Yes, when testing for equality you have to compare the hole
> } structure.
> Sorry I wasn't clear. I want to test if there is a valid pid
> stored in the erlang_pid struct. Is it safe to say that if
> ((erlang_pid *)->num == 0) that there is no valid pid stored
> there? That is to say that num is always greater than 0 in
> a pid (if we ignore the otp_ring process which I will never
> want to send to)?
I'm not sure that I understand you right, but my guess is that you
want to mark an erlang_pid structure as invalid. Setting the num
member to 0 won't work even if you consider <X.0.0> as invalid
since <X.0.1> could be a pid of a process that you want to
communicate with. I'd set the node member to "" instead, i.e. if
(epid->node == '\0') then epid isn't a valid pid.
More information about the erlang-questions