Meyer, OO and concurrency

[Vance Shipley]

On Sat, Jul 16, 2005 at 01:55:34PM +0200, Nigel Head wrote:
}  
}  How do you find, for example, a particular server in a distributed
}  system, in particular when it might be moving from node to node if it
}  fails and gets restarted by the distributed application stuff ?

With functional programming you supply all the data required to
a function, instead of global variables you use arguments.  The 
same applies here, start the clients with the pid of the server.

I generally use registered processes if the client and server are
in seperate applications.  Within the same application it is usually
easy enough to initialize the client properly so that it knows where
it's server is.  Another trick I use is to inspect the supervisors.

-module(client).
-export([init/1, init_1/2, idle/2]).
-behaviour(gen_fsm).
-record(state, {sup, server}).

init(Sup) when is_pid(Sup) ->
   {ok, init_1, #state{sup = Sup}}.

init_1(timeout, State) ->
   MyGeneration = supervisor:which_children(State#state.sup),
   {value, {sister, Server, _, _}} = lists:keysearch(sister, 1, MyGeneration),
   {next_state, idle, State#state{server = Server}}.

idle(Event, State) ->
   ...
   gen_server:call(State#state.server, Request),
   ...

If processes are part of the same application you will have them all
under one supervision tree.  You can inspect the current children of
a supervisor to determine the pid of another process.  In the above 
we find the process which was started with the Id sister:

-module(sup).
-export(init/1).
-behaviour(supervisor).

init(_) ->
   ...
   ChildSpec = {sister,StartFunc,Restart,Shutdown,Type,Modules}
   ...
   {ok,{{RestartStrategy,MaxR,MaxT},[ChildSpec]}}
   


I found that most of my uses of registered processes were unnecessary.
The point was that it isn't functional style and as such should be
discouraged.  That isn't to say using them is wrong just that you should
be hesitant to do so.

	-Vance