Mark, I'm very interested in this and would love to see this progress. I was just taking a look at v8ken yesterday. It would be great to see some action happening on NodeKen.
Cool stuff. On Mon, Aug 12, 2013 at 5:19 PM, Mark Miller <erig...@gmail.com> wrote: > [+cutsem, +btulloh] > > Hi Tristan, you may be interested in a recent paper on Dr. SES by Tom Van > Cutsem, Bill Tulloh, and myself: < > http://research.google.com/pubs/pub40673.html>. In it we explain our > plans and hopes for Dr. SES, (Distributed Resilient Secure EcmaScript). I > say hopes because part of this depends on another project, NodeKen, that we > hope to be the successor to v8Ken <https://github.com/supergillis/v8-ken>, > but which is not currently in active development. (Tom, is this true?) For > NodeKen and Dr. SES, we expect we would proceed with one Node process per > actor, at least at first, since performance is not currently a priority for > this work. > > > > On Mon, Aug 12, 2013 at 6:39 AM, Tristan Slominski < > tristan.slomin...@gmail.com> 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? >> >> 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/<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 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. >> >> >> > > > > -- > Text by me above is hereby placed in the public domain > > Cheers, > --MarkM > > -- > -- > 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. > > > -- 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.
