[ACCEPTED]-Can someone explain the structure of a Pid (Process Identifier) in Erlang?-pid

Printed process ids < A.B.C > are 17 composed of 6:

• A, the node number (0 is the local node, an arbitrary number for a remote node)
• B, the first 15 bits of the process number (an index into the process table) 7
• C, bits 16-18 of the process number (the same process number as B) 7

Internally, the process number 16 is 28 bits wide on the 32 bit emulator. The 15 odd definition of B and C comes from R9B 14 and earlier versions of Erlang in which 13 B was a 15bit process ID and C was a wrap 12 counter incremented when the max process 11 ID was reached and lower IDs were reused.

In 10 the erlang distribution PIDs are a little 9 larger as they include the node atom as 8 well as the other information. (Distributed PID format)

When an 7 internal PID is sent from one node to the 6 other, it's automatically converted to the 5 external/distributed PID form, so what might 4 be <0.10.0> (inet_db) on one node might end up as <2265.10.0> when 3 sent to another node. You can just send 2 to these PIDs as normal.

% get the PID of the user server on OtherNode
RemoteUser = rpc:call(OtherNode, erlang,whereis,[user]), 

true = is_pid(RemoteUser),

% send message to remote PID
RemoteUser ! ignore_this, 

% print "Hello from <nodename>\n" on the remote node's console.
io:format(RemoteUser, "Hello from ~p~n", [node()]). 

For more information 1 see: Internal PID structure, Node creation information, Node creation counter interaction with EPMD

If I remember this correctly the format 9 is <nodeid,serial,creation>. 0 is current node much like a computer 8 always has the hostname "localhost" to refer 7 to itself. This is by old memory so it might 6 not be 100% correct tough.

But yes. You could 5 build the pid with list_to_pid/1 for example.

PidString = "<0.39.0>",
list_to_pid(PidString) ! message.

Of course. You 4 just use whatever method you need to use 3 to build your PidString. Probably write 2 a function that generates it and use that 1 instead of PidString like such:

list_to_pid( make_pid_from_term({proc_name, Node}) ) ! message

Process id < A.B.C > is composed of:

• A, node id which is not arbitrary but the internal index for that node in dist_entry. (It is actually the atom slot integer for the node name.)
• B, process index which refers to the internal index in the proctab, (0 -> MAXPROCS).
• C, Serial which increases every time MAXPROCS has been reached.

The 3 creation tag of 2 bits is not displayed 2 in the pid but is used internally and increases 1 every time the node restarts.

The PID refers to a process and a node table. So 6 you can only send a message directly to 5 a PID if it is known in the node from which 4 you do the call.

It is possible that this 3 will work if the node you do the call from 2 already knows about the node on which the process is 1 running.

Apart from what others have said, you may 5 find this simple experiment useful to understand 4 what is going on internally:

1> node().
nonode@nohost
2> term_to_binary(node()).
<<131,100,0,13,110,111,110,111,100,101,64,110,111,104,111,
  115,116>>
3> self().                
<0.32.0>
4> term_to_binary(self()).
<<131,103,100,0,13,110,111,110,111,100,101,64,110,111,104,
  111,115,116,0,0,0,32,0,0,0,0,0>>

So, you can 3 se that the node name is internally stored 2 in the pid. More info in this section of Learn You Some 1 Erlang.