i have, and it's great. i don't have code to share, nor would you want to see
the mess i made of it at the time. once piece of advice, if you're looking to
build a real system instead of just playing around: make sure you build it
on top of the OTP framework, not just erlang. erlang is a cool language.
erlang/otp is a system for building production quality services. there're
a few tutorials at trapexit.org and elsewhere, and joe armstrong's got a
new book coming out at pragmatic programmers.
you'll probably get better response posting to erlang-q...@erlang.org.
----
Garry Hodgson, Senior Software Geek, AT&T CSO
nobody can do everything, but everybody can do something.
do something.
> Is anyone on the list using Erlang for grid computing?
no sooner had i replied to you than i saw this on erlanq-questions:
Christoph Dornheim <c...@gmx.de> wrote:
> I have just added a tutorial "A framework for clustering
> generic server instances" to trapexit.org that can be found at
>
> http://wiki.trapexit.org/index.php/Category:HowTo
GH> jsnX <jason...@gmail.com> wrote:
>> Is anyone on the list using Erlang for grid computing?
GH> no sooner had i replied to you than i saw this on
GH> erlanq-questions:
GH> Christoph Dornheim <c...@gmx.de> wrote:
>> I have just added a tutorial "A framework for clustering generic
>> server instances" to trapexit.org that can be found at
>>
>> http://wiki.trapexit.org/index.php/Category:HowTo
I haven't commented on the howto (I've only browsed it quickly),
but in this particular forum, I'd like to comment that another
interesting framework is gen_leader. Gen_leader is a generic
leader election behaviour. Thomas Arts and Hans Svensson did
some really good work on it, identifying a suitable leader
election algorithm for erlang, and verifying the solution
using model checking, abstract traces and QuickCheck.
http://www.cs.chalmers.se/~hanssv/leader_election/
It's quite easy to use. An example program illustrates
a replicated dictionary, where each update to the
dictionary is replicated as a function object, and
performed on each copy of the dictionary (other
strategies are of course possible.)
new(Name, Candidates, Workers) ->
gen_leader:start(Name,Candidates, Workers,
test_cb, dict:new(), []).
-define(store(Dict,Expr,Legend),
gen_leader:leader_call(Dict, {store, fun(D) ->
Expr
end})).
-define(lookup(Dict, Expr, Legend),
gen_leader:call(Dict, {lookup, fun(D) ->
Expr
end})).
%% dict functions that modify state:
append(Key, Value, Dict) ->
?store(Dict, dict:append(Key,Value,D), append).
append_list(Key, ValList, Dict) ->
?store(Dict, dict:append_list(Key,ValList,D), append_list).
...
fetch(Key, Dict) -> ?lookup(Dict, dict:fetch(Key,D), fetch).
fetch_keys(Dict) -> ?lookup(Dict, dict:fetch_keys(D), fetch_keys).
...
The following code in the callback module makes it all
work:
%%% call directed to the leader instance:
handle_leader_call({store,F}, _From, Dict, _E) ->
NewDict = F(Dict),
{reply, ok, {store, F}, NewDict};
handle_leader_call({leader_lookup,F}, _From, Dict, _E) ->
Reply = F(Dict),
{reply, Reply, Dict}.
%%% event propagated from the leader:
from_leader({store,F}, Dict, _E) ->
NewDict = F(Dict),
{ok, NewDict}.
%% local call
handle_call({lookup, F}, _From, Dict) ->
Reply = F(Dict),
{reply, Reply, Dict}.
BR,
Ulf W
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Team Leader, Software Characteristics
/ / / Ericsson AB, IMS Gateways