Hey Tristan, Thanks for your feedback. Responses are inline.
On Mon, Aug 12, 2013 at 9:39 AM, Tristan Slominski < [email protected]> wrote: > 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? > I'm thinking of thousands of actors in a system or few actors with exceptionally high throughput. The chattiness of all actors impacts the latency of communication across the entire (local) system. Actors owning their own event loop circumvents that problem (i.e., an Actor can only slow/block its own event loop with its own behavior or by undergoing some sort of Actor DoS attack.) I've implemented a small actor framework in Node, and I'm using setImmediate to queue message delivery asynchronously on a single event loop. It's not parallelism I'm concerned about; it's more about having protection against blocking the entire system. > 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? > It's not where we need to start, but I think it's key to implementing a solid solution with this sort of design. Erlang's scheduler has evolved into this. If I could utilize an existing implementation (TBB), it might fast-track the entire concept. I'm open to using a simpler scheduler if it's easier to integrate. The purpose of a work-stealing scheduler is to maximize CPU power per task, potentially across cores. I believe this concept is also used in game development. (Again, not an expert on this.) > 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. > You're right about Erlang. Erlang uses process IDs as addresses. One could potentially guess a process ID. In my own little system, I am using strings for addresses, but Actors don't explicitly call other actors using a previously defined set of strings. When an Actor creates another, its address is passed to the new object. When communicating between actors, responses are usually sent using continuations associated with received messages. I need to beef up acquaintance sharing a bit, but that's where it is today. It does not implement a true Object Capability Model. Again, strings are fairly guessable. I do agree this is important, but setting up conventions that addresses are opaque leaves the opportunity to change the underlying implementation. > 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. > I agree with this. This could also apply when running multiple Actor threads per process. > 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). > Actor communication is where this all started for me. I spec'd/registered a MIME type for JSON-based hypermedia interaction. I want to experiment with this as the communication mechanism between Actors. Mostly, because that sounds fun. :) > I'm happy to talk at length about this stuff and perhaps collaborate. Ping > me if you'd like. > Appreciate the advice! I'd be excited to check out your new project. Thanks. > > 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/<http://threadingbuildingblocks.org/> >> [2] >> http://supertech.csail.**mit.edu/cilk/<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. > > > -- 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.
