Google tells me that it's Erlang.I can't understand it for the life of me, but It looks like a small server process, maybe doing unnatural acts on processes.
This is Erlang code. I'm not fluent in Erlang, but I think it starts some Erlang processes and delegates handling of messages to one of those services. Every time this process receives a message it delegates the message to the next "child process".
Using lists:nth in this way is a bad idea. Quadratic behaviour ahoy!
Possible fixes:
1) switch to using arrays or one of the dictionary libraries
2) change your state to keep two lists: the processes you haven't used this round yet, and the ones you have. When the first list runs out, reverse the second and use it again.
Additionally, it's now trivial to add more processes, if desired.
Comments
It looks like a functional language, maybe f# or Clojure returning a list messages
Google tells me that it's Erlang.I can't understand it for the life of me, but It looks like a small server process, maybe doing unnatural acts on processes.
This is Erlang code. I'm not fluent in Erlang, but I think it starts some Erlang processes and delegates handling of messages to one of those services. Every time this process receives a message it delegates the message to the next "child process".
Don't know Erlang either, but I think I spot some syntax errors/typos:
{stop, normal, State ); --> {stop, normal, State }.
an in handle_call() I guess there's a } missing at the end before the dot, as well as a (maybe optional?) comma in terminate() after ... = State.
I might be wrong though.
its lambda expressions in F# I think but am not sure
It is a map/reduce algorithm written using the gen_server behavior from the OTP erlang library.
Wow, so that's THE map/reduce... I'm totally disappointed, after having heard so much about it i expected it to have at least 200 lines of code.
Nice to see Myspace implementation:
http://code.google.com/p/qizmt/
load balancer in erlang code.
Cadet354,
Great! You got it!
Now, how does it work? :-)
init runs Num threads.
handlecall (Msg, From, State) handled asynchronously (genserver: cast) request.
(Processes, (CurrentIndex +1) rem Num, Num) selects the next thread that will work.
P.S. I apologize for my bad English
Cadet354,
I'll quibble with threads vs. processes, but you are correct.
Yes, lightweight erlang threads, not OS threads.
@Ayende: Is it something that you've built or did you find the code in some other app?
If you built it, for what project do you use it? I am thinking about Erlang course that we've participated one week ago :-)
It was a sample code that I had written in that course.
Using lists:nth in this way is a bad idea. Quadratic behaviour ahoy!
Possible fixes:
1) switch to using arrays or one of the dictionary libraries
2) change your state to keep two lists: the processes you haven't used this round yet, and the ones you have. When the first list runs out, reverse the second and use it again.
Additionally, it's now trivial to add more processes, if desired.
@Oliver
Your first correction is wrong, the other two are right