I wouldn't like to build an actor model directly on ZeroMQ as you can do better for in memory transport than ZeroMQ and you may want to place some actors on the same server .. as the implementation for an abstract Actor framework is fine just don't tie it to the implementation.
Regarding threads have you considered the "Disruptor pattern" eg remove all thread contention and use a disruptor ( a fancy ring buffer) to communicate. Also in an actor setup you don't normally have 10K actors , typically an actor is more likely to handle all requests for that type of entity (and i doubt you have 10K different types) . And if it gets to busy you load balance it with more workers. If you have even 500 active actors performance would be horrible due to context switches. Ben On Sat, Dec 15, 2012 at 7:27 PM, <[email protected]> wrote: > ts 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. >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
