ArT_Actors: A Step beyond Actor Framework 3.0?

[drjdpowell]

AristosQueue wrote:

Honestly, until a couple months ago, I never even thought about an actor using *another actor's* queue to pass into Launch Actor.vi. Then someone wanted to do it and I though, "Holy cow. What an insane idea." It is completely an abusive hack to even think about doing that. Don't. Nothing we have said about the positive benefits of the actor tree holds true if one actor go launching actors on behalf of other actors. Total mess.

Ah, see, that's what I was worried about.  People will abuse the system, and the current Actor Framework doesn't give them relatively safe channels to do that.  Once you break the tree, even in less agreggious ways like sharing an actor's message queue, things can go rapidly down hill.  Thus the need to VERY clearly explain the need for a strict tree.  And, IMHO, the value in coming up with a way of providing limited-scope cross-connects across the tree, such as allowing a Caller Actor to register one subactor to receive specific published messages from another subactor. 

-- James

[drjdpowell]

Dmitry wrote:

Based on the above I would take the following approach:

1. Do not introduce extra loops to Actor Core without a good reason (i.e. if Actor Message Loop may properly handle new functionality)
2. If you do add an extra loop - be prepared to spin it off as a subactor later on (recommended way to scale Actor Core)
3. ....

Actually, I've found that auxiliary loops in my actor designs are quite often one-to-one with things the actor has to wait for.  Waiting for a new measurement; waiting for bytes on a TCP connection; waiting for communication from a physical device.  The actor's message loop is, of course, waiting for incoming messages, so it can't be waiting on anything else unless one uses polling.  And these auxiliary loops, already waiting on something, can't be spun off as message-waiting subactors.

I do tend to only use one such auxiliary loop per actor, following the principle that each actor handles one thing (so, for example, the "TCP Listener Actor" launches "TCP Connection" subactors, rather than handle the incoming connections itself).