> Then, if understand well, Actors are like cell, in other words when the
> system starts all the Actors must be instantiated and will be persistent.
>
Not necessarily. You could have an actor configuration that starts with
only one actor. You could think of that actor as a seed out of which
Ummm... regarding:
"when the actor finished their job it calls the method (in node will be a
callback) "next", where it pass a message"
AFAIK, the actor don't call a method like "next". The actor:
- receives messages
- in the process of each message *can* emit other messages to other actors
and
Then, if understand well, Actors are like cell, in other words when the system
starts all the Actors must be instantiated and will be persistent. Acts like a
web, some actors just pass messages to others (proxy).
The part I don't understand well its, when the actor finished their job it
calls
Some things stand out in the approach so far.
The actors in the test are stateless. They do computation, but do not
maintain internal state that affects follow-on communication.
Addressing the above will reveal that "require" approach is not sufficient.
When you "require" a module, the module i
Here is on what I working... https://github.com/norman784/node-actor-test feel
free to criticise it...
--
--
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 Go
I was testing different approach to implement actors:
Fork: (child_process.fork) each actor as a new process
Pros: was isolation, if the actor crash just fork it again.
Cons: memory, each process are about 20mb.
Require: (just require every actor when needed) ie:
require('./actors/my_actor')(me
The usual problem with copying Akka design is:
var ref = system.actorFor(path);
The above line violates object capability security model
(see: http://en.wikipedia.org/wiki/Object-capability_model). It's a known
and admitted problem of Akka actors. It is very convenient for development,
and it
Hi people!
I don't know enough about Akka actors, Alexei. But in my pet project:
- no callback, you send a message to an actor reference, and voila
- no threads, only use the force of Node.js ;-) as usual, it leverages any
async i/o processing
I don't like to refer an actor by name (including ma
> Akka system
As far as I know Akka isn't true actor framework. It offer two ways
- Actors backed by threads - simple to use, but not good for performance
- Asynchronous actors - good performance but hard to use (same async stuff,
with same callback hell and other problems).
True actor - when y
Hey Norman,
To address some of your comments I'd like to point out some assumptions
that may or may not be true.
For example, an assumption that Kernel is separate from an actor system.
One of the things I've been looking at recently is to write a "kernel" in
actors. But, there already exist p
So many new concepts here to me, and thats teach me that I'm just know almost
nothing.
I would like to develop a library, only for learning purpose, I'll read those
links that Tristan shares.
Angel seems very interesting your project, its also for learning purpose yet?
There is so many things
Interesting thread, lot of good resources and discussion
Since my past year email, I updated my pet project, to reflect more a
(very) simplified Akka system:
https://github.com/ajlopez/SimpleActors
Angel "Java" Lopez
@ajlopez
On Wed, Sep 25, 2013 at 10:25 AM, Matthew Browne wrote:
> On 9/25
On 9/25/13 9:06 AM, Alexey Petrushin wrote:
I'd personally prefer actor to reactor because it's simpler to use.
For me working with isolated independent things is much simpler than
with state machine and recursions.
I agree. Events can help prevent callback pyramids to some degree, but
with act
I'd personally prefer actor to reactor because it's simpler to use. For me
working with isolated independent things is much simpler than with state
machine and recursions.
As about the performance - I don't care much, node already fast enough.
On Wednesday, July 24, 2013 9:17:24 AM UTC+4, Matthe
Hey Norman,
I highly recommend Dale's blog series on
Actors: http://www.dalnefre.com/wp/ (start with oldest and work your way
forward in time). It is well documented with lots of references to
interesting writings.
In particular to your comment on "I need a system that can run continuous
an
Thanks for the resources…
I read somewhere in this groups that c extensions may slow down nodejs, and
fibers just is written in c++, don't know yet how it may affect the performance
of the app that uses it.
Regards
--
Norman Paniagua
On Tuesday, September 24, 2013 at 12:32 PM, Matthew Br
If you want to learn more about the actor model, I highly recommend
looking into some resources by its creator, Carl Hewitt. In particular,
check out this video:
http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-t
This concept its new for me, but as far as I read this approach it good to
solve other problems that cannot be solved with the traditional paradigm.
In my case I need a system that can run continuous and can be fault
tolerant, maybe its more memory expensive this approach but in terms of
system
On 7/26/13 3:12 PM, Mark Hahn wrote:
I have heard that actors such as used by Apple are slow. Is this true
in general?
I am just learning about actors myself, but the comparisons I've seen
online between event loops and actors generally seem to suggest that
actors are equally fast as event loo
I have heard that actors such as used by Apple are slow. Is this true in
general?
On Fri, Jul 26, 2013 at 9:13 AM, Matthew Browne wrote:
> Hi Tristan,
> Thanks for the clarification.
>
> I was wondering, do you think it might be useful to implement Actors using
> the fibers module (https://npmj
Hi Tristan,
Thanks for the clarification.
I was wondering, do you think it might be useful to implement Actors using
the fibers module (https://npmjs.org/package/fiber)?
I noticed that there's an Actors lib for Ruby implemented with fibers:
https://github.com/tarcieri/revactor
It seems like this
In this context, implementing actors can be thought of as a pattern. I've
implemented actor frameworks from scratch on a number of different
"substrates". Much like one can implement a JVM in JavaScript, one can
implement an actor system on top of Node.js. All the way down, something
must anima
Hi,
I realize this thread is a little old, but I just came across it I don't
understand your reasoning...yes, Reactor (event loop-based approach) is a
different approach than Actors, but Actors have been implemented
successfully on top of event loops in some other languages like Python and
have
I haven't taken it up to tens of thousands of processes, but here's my pet
project:
https://github.com/tristanls/anodejs
It naively uses process.nextTick for sending a message, which negatively
affects performance (the correct answer is an optimisation based on what
node.js release you have th
I'm not sure that Reactor (Node.js) should be used with Actors. It seems
that it's a different approaches for solving the same problem - concurrency.
If JS would have ability to spawn tons of cheap processes - then we just
don't need such limitation as Node.js async API.
So, it seems it's not j
25 matches
Mail list logo
