Ummm... interesting Why not to put an actor running in one Node.js process? Every goal you mention is satisfied by such arrangement
Or few actors per Node Node using cluster module in the same machine? Many Nodes by machine, and then, many machines? My experiments http://ajlopez.wordpress.com/2013/05/30/aplicaciones-distribuidas-y-node-js/ there is a short section, actors a la Akka Angel "Java" Lopez @ajlopez On Sun, Aug 11, 2013 at 7:38 PM, Kevin Swiber <[email protected]> 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
