Passing a digraph between processes on the same node

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Passing a digraph between processes on the same node

Steve Davis
Hi,

Somehow I’m not seeing why the following fails:

-module(gtest).
 
-export([test/0]).
 
test() ->
                Test = self(),
                spawn(fun() -> graph(Test) end),
                receive
                {ok, G} ->
                                digraph:vertices(G)
                after 5000 ->
                                timeout
                end.
 
graph(Pid) ->
                G = digraph:new(),
                digraph:add_vertex(G),
                Pid ! {ok, G}.

…since the backing ets table is “protected" by default, shouldn’t the calling process be able to read the values set by the process that builds the digraph?

(It’s probably trivial and me being dumb).

ty for your time,

/s

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Passing a digraph between processes on the same node

Steve Vinoski-2

On Tue, Jun 9, 2015 at 7:55 PM, Steve Davis <[hidden email]> wrote:
Hi,

Somehow I’m not seeing why the following fails:

-module(gtest).
 
-export([test/0]).
 
test() ->
                Test = self(),
                spawn(fun() -> graph(Test) end),
                receive
                {ok, G} ->
                                digraph:vertices(G)
                after 5000 ->
                                timeout
                end.
 
graph(Pid) ->
                G = digraph:new(),
                digraph:add_vertex(G),
                Pid ! {ok, G}.

…since the backing ets table is “protected" by default, shouldn’t the calling process be able to read the values set by the process that builds the digraph?

The process running graph/1 is the owner of the ets tables. It dies as soon as the graph/1 function completes and it takes the ets tables down with it.

Add two calls to ets:i/0, one right after receiving {ok,G} and the other right after the digraph:new/0 call, then run gtest:test/0 from the shell and you'll see that the digraph-related ets tables disappear by the time the receive handles the message.

--steve

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Passing a digraph between processes on the same node

Steve Davis
Ouch. OK, I totally see it. 

tysm Mr. V!


On Jun 9, 2015, at 7:55 PM, Steve Vinoski <[hidden email]> wrote:


On Tue, Jun 9, 2015 at 7:55 PM, Steve Davis <[hidden email]> wrote:
Hi,

Somehow I’m not seeing why the following fails:

-module(gtest).
 
-export([test/0]).
 
test() ->
                Test = self(),
                spawn(fun() -> graph(Test) end),
                receive
                {ok, G} ->
                                digraph:vertices(G)
                after 5000 ->
                                timeout
                end.
 
graph(Pid) ->
                G = digraph:new(),
                digraph:add_vertex(G),
                Pid ! {ok, G}.

…since the backing ets table is “protected" by default, shouldn’t the calling process be able to read the values set by the process that builds the digraph?

The process running graph/1 is the owner of the ets tables. It dies as soon as the graph/1 function completes and it takes the ets tables down with it.

Add two calls to ets:i/0, one right after receiving {ok,G} and the other right after the digraph:new/0 call, then run gtest:test/0 from the shell and you'll see that the digraph-related ets tables disappear by the time the receive handles the message.

--steve


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions