Thanks to visit codestin.com
Credit goes to github.com

Skip to content

pid weirdness with gproc_dist #141

@uwiger

Description

@uwiger

I came across this. I won't claim that it's a bug in Erlang - I assume there was a hickup in the networking on my Mac - but I must say that I can't even remember having seen this before.

(I believe Hans Svensson talked about something similar in Freiburg 2007).

Running some gproc tests with two local nodes. OTP 18, for no particular reason.

Node A:

Erlang/OTP 18 [erts-7.3.1] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V7.3.1  (abort with ^G)
(a@uwpro-2)1> application:ensure_all_started(gproc).
{ok,[gproc]}

Node B:

Eshell V7.3.1  (abort with ^G)
(b@uwpro-2)1> net:ping('a@uwpro-2').
pong
(b@uwpro-2)2> application:ensure_all_started(gproc).
{ok,[gproc]}
(b@uwpro-2)3> gproc:monitor({n,g,a},follow).
#Ref<6830.0.4.170>
(b@uwpro-2)4> flush().
Shell got {gproc,unreg,#Ref<6830.0.4.170>,{n,g,a}}
ok

Node A:

(a@uwpro-2)2> ets:tab2list(gproc).
[{{<6946.39.0>,{n,g,a}},[]},
 {{<6946.39.0>,{n,g,a}},[]},
 {{{n,g,a},n},[{<6946.39.0>,#Ref<0.0.4.170>,follow}]}]
  • Oops! The 'gproc' table is an ordered_set, so the above looks impossible.
(a@uwpro-2)4> ets:lookup(gproc, {pid(6946,39,0),{n,g,a}}).
[]
  • Uhmm ...
(a@uwpro-2)8> [A,B,C] = v(2).                   
[{{<6946.39.0>,{n,g,a}},[]},
 {{<6946.39.0>,{n,g,a}},[]},
 {{{n,g,a},n},[{<6946.39.0>,#Ref<0.0.4.170>,follow}]}]
(a@uwpro-2)9> ets:lookup(gproc,element(1,A)).
[{{<6946.39.0>,{n,g,a}},[]}]
(a@uwpro-2)10> ets:lookup(gproc,element(1,B)).
[{{<6946.39.0>,{n,g,a}},[]}]
  • Ok, so the two objects are both individually accessible.
(a@uwpro-2)11> A == B.
false

(a@uwpro-2)13> Pa = element(1,element(1,A)).
<6946.39.0>
(a@uwpro-2)14> Pb = element(1,element(1,B)).
<6946.39.0>
(a@uwpro-2)15> Pa == Pb.
false
  • The two pids are not the same.
(a@uwpro-2)18> term_to_binary(Pa).
<<131,103,100,0,9,98,64,117,119,112,114,111,45,50,0,0,0,
  39,0,0,0,0,1>>
(a@uwpro-2)19> term_to_binary(Pb).
<<131,103,100,0,9,98,64,117,119,112,114,111,45,50,0,0,0,
  39,0,0,0,0,2>>
  • The pids have different serials. Presumably this means that the nodes have disconnected and reconnected (and gproc should have cleaned up, but didn't)
(a@uwpro-2)20> Pa ! hi_a.
hi_a
(a@uwpro-2)21> Pb ! hi_b.
hi_b

Node B:

(b@uwpro-2)5> flush().
Shell got {gproc,unreg,#Ref<6830.0.4.170>,{n,g,a}}
Shell got hi_b
ok
  • So one pid worked, the other one didn't.

A bit interesting to try to reproduce, I guess.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions