-
-
Notifications
You must be signed in to change notification settings - Fork 236
Open
Description
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}}
okNode 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_bNode 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
Labels
No labels