On Mon, Aug 12, 2013 at 3:22 PM, Tristan Slominski <
[email protected]> wrote:

> Hey Kevin,
>
> I looked for your actor framework on your github but didn't find it. Is it
> available?
>

 Nope.  It's just a quick POC I threw together.  Nothing ground-breaking, I
don't believe.  I only set out to implement a minimal API surface.  Kind of
the complete opposite of Akka.  :)


> Also, what does it mean for an actor to own it's own event loop? If I have
> an actor that enters an infinite loop (I'm assuming I'm writing actor
> behaviors in javascript) and never exit the handler for event, how can I
> protect against that without having it in a separate thread/process while
> still running inside single threaded Node.js process (a restriction you
> mentioned that is desirable)? Multiple processes will not scale to
> Erlang-comparable numbers of actors.
>

I remember a project called Tripwire (https://npmjs.org/package/tripwire)
that attempts to kill blocking code.

With the design I'm proposing, creating an actor will spawn a new thread
with its own event loop waiting to receive messages.  I'm not sure on the
cost of that, but it would be interesting to find out.


>
> 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.
>>
>
> One way of accomplishing this within a single Node.js process is using
> javascript object identity as actor addresses. They are unique and you
> cannot forge a reference to it.
>
> actorAddress1 = {};
> actorAddress2 = {};
> actorAddress1 === actorAddress2; // false
>
> And you can freeze it for good measure:
>
> Object.freeze(actorAddress1);
>

Sure, but those addresses don't work when you scale beyond a single
process.  I'm not sure how to solve that problem yet.


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.


Reply via email to