Actor Message queue creation and access before Launch Root or Launch Nested

[tadders]

For an Actor create and allow access to its Message Queue before calling Launch Root / Launch Nested Actor.

This would allow easy association between Actor Objects before Launching them.

Association between Launched Actors needs a 'Set Associated' Queue mutator and related Message - all a bit fiddly.

[AristosQueue (NI)]

a) This change would break the contract that the system currently makes for Pre Launch Init.vi. An Actor always has dibs on adding to its own queue at all priority levels. If the queue exists before the Actor is launched, others may have added messages to the queue already.

b) This change would break the lifetime management contract of the Actor Framework. If the queue exists before the Actor then someone else has the lifetime of the queue -- the Actor is supposed to have the lifetime of the queue. Otherwise you send messages to the Actor and then quit and those final messages -- including the all important Stop message -- get dropped and the Actor has to do error shutdown instead of clean exit, possibly missing lots of final instructions.

c) Separating the queue from the Actor process would move the AF toward the model of separate processes establishing communications channels, which is the model that AF was explicitly moving away from.

d) This change would necessitate some registration system to make sure that the same queue was not given to launch multiple Actors. Such a registration system would add more weight to launching an actor.

Unless you can provide a much stronger case for why this is needed and how it can be done without breaking other promisies of the AF, I strongly recommend rejecting this idea for the NI Actor Framework.

Having said that, the AF is entirely G code with no passwords. You can make a copy of the AF and then modify it as you see fit. I would strongly advise against making this change, particularly because of the dropped-final-messages problem. If you want to discuss the use case that is leading you to make this suggestion, please post a new thread to the community. Perhaps one of us there can help you work around whatever the difficulty is that you're currently facing.

The AF Community: http://ni.com/actorframework

[Darren]

Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Actor-Message-queue-creation-and-access-before-Launch-...

[mthimm1]

You can create a temporary priority queue before you start the actor. When the actor has created its own queue you can flush the messages with normal priority. Like this you make sure that the actor can still manage high priority tasks.

To manage the lifetime of this queue seems a problem to me. You can wait for the actors own queue to come up but if this never happens you have to make sure that the queue dies. 

[AristosQueue (NI)]

mthimm1's idea falls afoul of the "drop last message" problem (unless you were strict about never enqueuing into the original queue any time after the actor was actually launched). And it injects race conditions caused by having two separate ways of communicating with an actor (a problem discussed at length in various threads in the AF forum). Yes, it can be done. It could even be done safely with enough scaffolding around it. I would discourage any developer from going down this road.

Why not just have an array of messages and as soon as you call Launch Actor, send all of those messages? No need to get any refnums involved whatsoever. [If you have multiple people who need to send to the actor, you've violated the prime rule of the AF anyway to respect the actor call tree.]

The better solution, if you need this separation, would be to launch a place-holder actor that all it does is receive and store messages. Eventually it gets another message that tells it to "Launch the real actor as a nested actor"... it would then launch the real actor and then pass along to it all the stored messages.

I have a hard time seeing a use case for this, but it would work and be entirely correct if you followed this pattern.

[mthimm1]

This is a very old thread, i didn't intend to bring it up again. I had to think about, intuitively it was clear to me that such a feature would be nice. Maybe I am wrong.

The use case could be the following:

Assume you have to nested actors of your root actor, lets say Alpha and Beta. When started, Alpha informs Root about its start (or about something else) and root reacts by sending a message to Beta. At this point in my humble opinion Beta is probably not yet started. Then the enqueuer is not available for the vi which reacts on the message. You can check if the the enqueuer is there and you should do, to avoid 1556. But then? How to deal with it?

I know, that the one of the design principles is "fire and forget", but here it seems to me that I have to forget without having a chance to fire. If there was the possibilty to store the message somewhere and try to send the message when the real enqueuer appears i would avoid this.

To use a queue instead of an placeholder actor might be nicer, because it can be created when I try to access the not-a-ref- Queue and can be replaced when the real queue exists as drop in replacement. You will have race conditions and you will have to care that this is not an issue.

I am not sure if i break a rule and I do not want to. It is always helpful to read your comments.

[AristosQueue (NI)]

mthimm1:

There's a flaw in your reasoning.

Root starts Alpha.

Alpha does its set up and then sends a message to Root.

Root knows whether it has started Beta or not. If it has already started Beta, it passes the message to Beta. If it has not started Beta, it can decide what to do with the message. It may choose to drop the message. It may choose to send a message back to Alpha to try again later. Or Root could store the message within itself and send that message when *Root starts Beta*.

Beta does not start ex nihilo and then tell Root, "Here I am." Beta is started by Root, and as soon as Launch Nested Actor returns, the queue for Beta is available for messages. There's no timing hole here. There is never a time when Root is unsure about the existence of Beta. 

So all Root needs is an array of messages in its private data to save all the messages intended for Beta that it will send when it gets around to starting Beta.

There's no need for a proxy queue of any sort to be built into the Actor Framework... this is functionality that is only useful to those few actors that need that kind of delayed processing of messages.