Hey Kevin,
I looked for your actor framework on your github but didn't find it. Is it
available?
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.)
>
That may be difficult to do in Node.js. For example, Erlang has customized
function calling conventions in assembly in order to be "fast". Compared to
that, JavaScript inside Node.js is interpreted, and therefore a few levels
of abstraction above Erlang's implementation, which will make it difficult
to have a really large numbers of actors with high "performance". All this
depends on system performance characteristics you're after.
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.
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);
Cheers,
Tristan
--
--
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.
