On Mon, Aug 12, 2013 at 3:55 PM, Kelly, Terence P (HP Labs Researcher) < [email protected]> wrote:
> Hi guys,**** > > ** ** > > Regarding Ken itself, here are pointers:**** > > ** ** > > Source: http://ai.eecs.umich.edu/~tpkelly/Ken/**** > > Conference paper on Ken: > https://www.usenix.org/system/files/conference/atc12/atc12-final206-7-20-12.pdf > **** > > Conference paper on kernel support for fast checkpointing: > http://ai.eecs.umich.edu/~tpkelly/papers/Failure_atomic_msync_EuroSys_2013.pdf > **** > > > I really hope that somebody can provide lots of encouragement and also > tangible support to Tom Van Cutsem & Co. for NodeKen, which everyone seems > to agree is extremely exciting. > Or help someone else make progress. > Mark, is Google planning to do anything to help Tom? > We have no such plans. > **** > > ** ** > > I'd be funding Tom myself except that my organization (HP Labs) cancelled > its external collaboration funding program this year. > ;) > **** > > ** ** > > -- Terence Kelly, HP Labs**** > > ** ** > > ** ** > > ** ** > > *From:* Mark S. Miller [mailto:[email protected]] > *Sent:* Monday, August 12, 2013 3:46 PM > *To:* [email protected] > *Cc:* Tom Van Cutsem; Tom Van Cutsem; Kelly, Terence P (HP Labs > Researcher) > *Subject:* Re: [nodejs] Re: An Erlang-like "process" model for Node.js**** > > ** ** > > [+terence] // creator of Ken**** > > ** ** > > ** ** > > Hi Kevin, I was hoping someone would react that way, thanks!**** > > ** ** > > Tom was very involved with the v8ken and NodeKen efforts. We would love to > see progress on this and would try to help. Have you taken a look at Ken > itself? (cc'ing Terence)**** > > ** ** > > ** ** > > ** ** > > On Mon, Aug 12, 2013 at 3:23 PM, Kevin Swiber <[email protected]> wrote:** > ** > > 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 <[email protected]> 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 < > [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? **** > > ** ** > > 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 [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. > > **** > > > > **** > > ** ** > > -- > 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 [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. > > **** > > > > **** > > ** ** > > -- > Cheers, > --MarkM **** > -- 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 [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.
