Sending a message to an actor (not from the caller) and sending a return message

[AristosQueue (NI)]

For the record, my next big push on AF will be trying to add a network layer. I'll have documents to post some time in the next couple weeks. I have some long conversations scheduled with a couple of security experts; I'd like to establish AF on a sound foundation since it will explicitly be a system for remote deploying code, and I want to make sure we build it right from the start.

[tst]

There is one problem I'm seeing with the AF for this - in the AF processing the message is delegated to the message class, but that doesn't work if you want different actors to handle the same message differently. This may not be an issue if you spend a specific message to a specific actor, but it does become one if you want to publish to several.

There are solutions for this (such as adding a subclass of named messages (or getting the message class name) and using the name to cast to the correct class inside the actor and get the data you need for actor-specific behavior), but I thought that was part of what the AF was supposed to make unneeded.

[drjdpowell]

That's a general issue with "Command Pattern" messages; they naturally "belong" to the receiver.  Many different senders can send the same message, but each receiver needs a custom version.  The customisation can be by child classes, so one doesn't necessarily need to resort to named messages, but that does seem a lot of effort.  Personally, I have only yet used the Command Pattern in a couple of cases where there is only one receiver; mostly I use named messages and a case structure.

-- James

[Daklu]

tst wrote:

There are solutions for this (such as adding a subclass of named messages (or getting the message class name) and using the name to cast to the correct class inside the actor and get the data you need for actor-specific behavior), but I thought that was part of what the AF was supposed to make unneeded.

Dynamic dispatching is single dimensional--it only works along one axis.  In this case that axis is the message class.  You're asking it to dispatch across two axes:  the message class and the actor class.  Can't do that.  There's no way for the message class to dynamically dispatch to a subclass based on the actor class.  You have to either check the message type (or name) and manually downcast the message object (a la LapDog) or associate each message class with a specific actor (a la Actor Framework.)

tst wrote:

This may not be an issue if you spend a specific message to a specific actor, but it does become one if you want to publish to several.

I find it useful to think of messages in terms of "input" and "output" messages.  All messages are defined somewhere--usually a message definition is owned by an actor.  An input message is a message defined by an actor that other actors send to it.  An output message is one defined by an actor that it sends to other actors.

Sending the same message to many different actors violates what in my opinion is one of the principles of the Actor Framework.  Namely, all messages are input messages.  Because the message also defines the actions taken when the message is received, output messages don't really exist in the Actor Framework.  Broadcasting a single message directly to multiple actors puts the sender in control of the message definition, which can easily lead to higher coupling and confusing dependency trees. 

Instead, implement a publisher as an intermediary.  Have the sending actor send its message to the publisher, and have the publisher send each subscriber the unique message it is expecting for that event.  Implementation details vary depending on what you need:  i.e. You can write the publisher as a man-in-the-middle or as a wrapper around your sending actor.  You can implement dynamic registration by using a call back mechanism or take the simple route and statically link the publisher to the subscribers.

[AristosQueue (NI)]

I actually have a working prototype for solving the double dispatch problem based on dynamic registration tables. It's still clunky, but the clunkiness is at least all behind the scenes of the Message class, not in the face of its users. Dynamic dispatching has O(1) time complexity. What I've got is an O(N) solution, where N is the number of message types in the lookup table. In theory, I should be able to get this to O(log N), but my performance benchmarks say otherwise. I've managed to avoid any string name comparison by mapping the names over to integers by essentialy doing what the linker does at load time to build the dynamic dispatch table and doing that work at first call instead. The hard part is the thread synchronization in G -- finding something that doesn't create locking when two parallel message receivers need to lookup the message dispatch at the same time. Any shared resource in G creates binding, so I either replicate that or find a way to add features to LabVIEW. The replication turns out to have some nice side effect features, so I'm going down that road and see how far I can get... the tables are pretty small, and its one per receiver, not one per message, so I'm thinking that's going to be reasonable.

I'm still kicking the tires on this, but I think it'll be an effective G solution in a couple months.

Oh, and if you think I'm being coy about releasing this, it's because I wrote something in my first draft where I used some private functions of LabVIEW and I accidentally created a system that removed all the library encapsulation from LabVIEW, giving a backdoor way to call private/protected/community scope VIs from anywhere. Having realized this, luckily, before I posted any code, I'm being very careful to make sure not to repeat that mistake. 🙂