| Author |
Message |
< Erlang ~ erlang global module |
| darkolee |
 Posted: Sat Mar 06, 2010 9:57 pm |
 |
|
|
User
Joined: 02 Dec 2009
Posts: 12
|
Is this a bug with the global module?:
I start two erlang shells. On the first one I globally register a process (using global:register_name(arnie, Pid) ). Then I go on the second shell, and call the following line from the shell:
net_adm:world(), global:whereis_name(arnie).
undefined
Why did I get undefined?????
The erlang shell says the name is undefined. If I try to rerun the same command again, or simply run global:whereis_name(arnie) then I DO get the Pid of the process. So the problem occurs only when the two statements are called directly together immediately after the erlang shell is started.
Any thoughts/ideas? Am I overlooking something? |
|
|
| Back to top |
 
|
| bpuzon |
| Posted: Sun Mar 07, 2010 12:17 pm |
|
|
|
User
Joined: 05 Aug 2009
Posts: 23
Location: Cracow, Poland
|
| Which Erlang version are you using? With R13B03 I was unable to reproduce the error (I did net_adm:ping/1 instead of net_adm:world/0 though). |
_________________
Saludos,
Bartłomiej Puzoń
Erlang Solutions |
|
| Back to top |
|
| darkolee |
| Posted: Mon Mar 08, 2010 10:49 pm |
|
|
|
User
Joined: 02 Dec 2009
Posts: 12
|
Just installed the R13B04 version but the problem still did not get solved on my pc...
Also tried it out using net_adm:ping() and the effect is the same on my pc.
To recap here is what I am doing. I am on Windows XP:
1) Open two erlang shells with:
erl -sname arnie
and
erl -sname bambi
2) On arnie execute the following two commands on the shell
Code:
A = spawn( fun()-> receive stopit -> ok end end).
global:register_name( arnie_process , A ).
3) On bambi execute the following line:
Code:
net_adm:world(), global:whereis_name(arnie_process).
Output on bambi is:
undefined
however if step 3 is done once again, the pid is returned. |
|
|
| Back to top |
|
| nick |
| Posted: Fri Mar 12, 2010 10:19 am |
|
|
|
Joined: 11 Mar 2010
Posts: 2
|
To give visibility to a name between two or more nodes is necessary to connect them with the function
net_kernel: connect_node/1 (http://ftp.sunet.se/pub/lang/erlang/doc/man/net_kernel.html#connect_node-1) |
|
|
| Back to top |
|
| darkolee |
| Posted: Fri Mar 12, 2010 12:06 pm |
|
|
|
User
Joined: 02 Dec 2009
Posts: 12
|
Hi
even if I execute:
net_kernel:connect_node('arnie@mypc'), global:whereis_name(arnie_process).
I get undefined on the first try, but get the pid on any successive attempts.
Note also that if I write net_kernel:connect_node('arnie@mypc').
and press enter.
And then write
global:whereis_name(arnie_process).
and press enter
I DO get the pid on the first try.
Using any of net_adm:ping() or net_adm:world() instead of net_kernel:connect_node() will not alter the output I am getting. Hence I suspect it is something wrong with the global module (or I am doing something wrong with it...)
Did anyone get this problem? Once again, I am one a Windows XP machine running otp version R13B04
Thanks |
|
|
| Back to top |
|
| jwatte |
| Posted: Fri Mar 19, 2010 9:36 pm |
|
|
|
User
Joined: 10 Feb 2010
Posts: 34
|
Is there a scheduler issue, where you have to let the scheduler switch to the right process before the name becomes visible?
Note that this isn't really a "bug" in the system, because any code that behaves in the way that you describe has an inherent race condition -- what if the second shell did the look-up before the first shell had had time to register the name?
I've seen similar annoying behaviors with simpler things, like whether a process is alive or not.
Code:
proc1() ->
receive
stop -> exit(normal);
Anything -> proc()
end.
other_code() ->
Pid = spawn( ... proc1 ... ),
Pid ! stop,
true = is_process_alive(Pid).
The match will succeed. I think this is just a fact of the implementation of the system -- messaging is asynchronous, but ordered (on a per-process basis).
Btw, if I insert a call to io:format() before the true match in that code, the match will fail, so apparently io:format() does something that (generally) causes the scheduler to switch enough to exit the other process. |
|
|
| Back to top |
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
