This question is of interest to me as well. Let me give some answers, I havent really implemented them yet:
1. Each thread has one socket. You hash the unique name of the actor and assign it accordingly to a thread. advantages: no contention. disadvantages: it cannot work if actors have different processing needs. You rely on the randomization of the hash function to balance the work. this is pretty useful for a graph processing system(millions++ of actors) 2.You have a central broker which implements a locking mechanism. Threads ask for work, they receive the actors name plus the message that needs to be processed. All the actors data are shared by all the threads. advantage:load balancing works all the time disadvantage: latency because each thread has to request for work. >From an algorithmic point of view, how is a disruptor pattern faster than a queue when we want to implement an actor model? I would be interested to know how akka or erlang solve the above problem of distributing actors to threads. 2012/12/15 Min Yu <[email protected]> > Akka on zeromq would be an another fun for you. > > http://doc.akka.io/docs/akka/snapshot/scala/zeromq.html > > > Thanks > Min > > Dec 15, 2012 9:01 PM Gleb Peregud <[email protected]> 작성: > > If you want the most natural way to code your program according to > actor model, just use Erlang. It has a zeromq library, hence you can > communicate with outside world using zmq. > > On Sat, Dec 15, 2012 at 12:27 PM, <[email protected]> wrote: > > > hi peeps, > > > i would like to ask you for some ideas/hints on an actor-model > > design on top of zeromq. zeromq ships with everything i need, > > a mailbox, message routing, i don't have to worry about threads etc. > > > i think the straightforward way would be to give every actor > > one or more sockets for sending and receiving messages, depending > > on the used patterns (pub-sub, req-rep). but it seems to be a big > > overhead, since the max. number of sockets per context is limited. > > on the other hand, i would have to share some sockets and write > > a lot of messaging features by myself. so zeromq would be useful > > just for the communication between some processes or nodes. > > > it's similar to an component based entity system, communication between > > entities<->entities, entities<->system and system<->system > > should be handled through an event/message bus. Although it's not for game > > development, 10k+ entities are possible, which would require > > at least more than 10k sockets. > > > thank you for your suggestions! > > > best regards, > > > wil > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > -- Sincerely yours, Apostolis Xekoukoulotakis
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
