Format of Pids

[Rickard Green]

Vance,

erl_interface and ei are currently being cleaned up, but this wont be
finished until (hopefully) R10B.

Vance Shipley wrote:
> Rickard,
> 
> 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] == '\0') then epid isn't a valid pid.

> 	-Vance
> 

Regards,
Rickard