I've been working on this type of problem from different angles for a few years now.
On top of Node.js it is relatively easy to build an actor framework, especially if you are familiar with actor patterns and how actors should communicate. I don't understand what problems you hope to solve with the actor model that don't fit a single event loop pattern? Actors are concurrent, any actor solution ought to be implementable on single event loop, perhaps not as efficiently as would be possible otherwise in Node.js. Do you have specific examples of synchronous operations that cannot be made asynchronous? This also refers to your other comment. What is the reasoning behind actors running in isolated event loops? Concurrency can be accomplished on one event loop. Are you looking for parallelism? What is the purpose of work-stealing scheduler? Is that where you need to start? Perhaps a design with a simple scheduler that can later be upgraded independently would be easier to do initially? I would say that one of your missing criteria is Object Capability (http://en.wikipedia.org/wiki/Object-capability_model). This is missing in Akka for sure, I think it is also missing in Erlang but I'm not as sure about that one. A good place to start is to make actor addresses unforgeable and force explicit actor address passing in messages (no implicit "sender" in messages). This enables you to reason (in mathematical proof sense) about security of your actor configuration. If you find yourself getting actors by name (from a string), you've lost object capability. This is not to be confused with externally known "receptionist" actors, there's a somewhat crowbar separation there. As far as how to break up actors so that they perform reasonably on Node.js, (and perhaps this is what you mean by running them in multiple event loops) actors that end up working together, tend to form what's commonly referred to in literature as actor configurations. You can think of configurations as somewhat analogous to linux control groups, that is, they can be sponsored with a fixed amount of resources (technically, every single actor can be sponsored, but it seems configurations are a better "batch size"). You could run a lot of configurations on the same event loop, but then, you could start multiple processes with actor configurations of their own. This is how you could start to abstract computation in a way that would be meaningful and bound to hardware resources that you have. This is also how you could start moving toward running untrusted code and actor isolation. Once you figure out how to comfortably scale on one machine, perhaps using multiple Node.js processes each running multiple actor configurations, then you'll have to solve the problem of actors being able to talk to actors on other machines. The centralized/single-point-of-failure way of doing that is relatively straightforward. I'm more interested in how to do it in a decentralized way. I have a project that is getting near ready to be tested that is an attempt at solving that (sort of Node.js userspace ZMQ-like point-to-point with Kademlia DHT discovery mechanism). I'm happy to talk at length about this stuff and perhaps collaborate. Ping me if you'd like. Cheers, Tristan Slominski Github: https://github.com/tristanls Twitter: @tristanls On Sunday, August 11, 2013 5:38:31 PM UTC-5, Kevin Swiber wrote: > > I'm contemplating an experiment to bring an Erlang-like "process" model to > Node.js. > > I'm curious if anyone has been down this path before or if there's prior > art I haven't stumbled upon yet. > > Background: I've been working with Node for a couple of years now. The > default answer to multi-threading Node is "don't do it." This experiment > challenges that advice. There are many benefits to multi-threading, though > they admittedly bring features not promised by Node core. I'm fine with > that. > > Inspiration: Erlang implements an Actor model for concurrency. A process > running in Erlang's VM runs on a thread underneath the covers. The VM > implements a work-stealing task scheduler to manage the load effectively. > From here on out, I'll refer to the "Erlang process" style pattern as an > Actor. (Note: I'm no expert in Erlang. Some of this might be wrong. :) > > The Node event loop is powerful, but unfortunately, not all operations are > asynchronous in nature. For problems whose solution does not fit the > single event loop pattern, I'd like to see an alternative emerge. > > Current thinking on design: > * Actors should have access to all Node's capabilities. > * Actors should run in isolated event loops. > * Actors should communicate via message passing. > * No shared state. > * Actors should take advantage of a V8 Isolate. > * A work-stealing task scheduler should be implemented under the covers. > * Actors can spawn other actors. > > The scheduler seems like one of the hardest pieces to implement (IMHO). > For that, it might be worth investigating Intel's Threading Building > Blocks[1] or the Cilk project[2]. > > Ideally, this could all be accomplished via modules without rewriting any > part of Node core. > > So... what am I missing? Is there a giant hurdle that makes this nearly > impossible? Distributed systems made of actors using arbitrary > computational complexity and having the ability to take advantage of the > Node ecosystem seems very compelling to me. > > [1] http://threadingbuildingblocks.org/ > [2] http://supertech.csail.mit.edu/cilk/ > > Cheers, > > -- > Kevin Swiber > Projects: https://github.com/kevinswiber > Twitter: @kevinswiber > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
