Recieve Queue.lvclass

[rpodsim]

I've been trying to figure out what the Recieve Queue class is for, it doesn't appear to be used anywhere but the Create Message Queue Pair.vi?

[justACS]

You're right, it's not used anywhere in the framework.  It was provided for symmetry.

[KuGr]

I changed that in my version of AF.  I did not like the raw Queue refnum to be accessible to derived Actor Core.vi's where it could be released prematurely.  So, I use the 'Create Message Queue Pair' in Actor.vi and changed Actor Core to take the ReceiveQueue class instead of the raw refnum.  Only Actor.vi, in my version, has the ability to release the Actor's Queue.

[justACS]

If your child actor had, say, a UI, how would it inject messages into its own core?  And why would you use the receive queue?  You certainly don't want your child actor's UI to *dequeue* messages...

[KuGr]

Very true, perhaps my answer was not complete.  In my version of AF v1.x, my Actor (derived from NI Actor) retained a wrapper class to a queue allowing all queue functions except release.  So, a UI Actor with it's own process loop (set up in its Actor Core override) would have access to the queue by accessing the member variables (Read and Write properties). 

When AF v2 came out, I still had LV 2010 code but I wanted to "keep up with the jones's" so I added some of the cool features in AFv2 including the Send and Receive Queue.  Since only Actor Core should receive messages, the Receive Queue was an input.  The Send Queue however was a private member and all derived classes had access to it, including a UI actor.  There was nothing to stop  a derived Actor Core from storing the Receive Queue and stealing my messages, but that was better than it killing my queue.

I may be a bit fuzzy on the details, but in AF v1 and v2 release, I was most concerned about the exposure of the raw queue refnum and some rogue developer releasing that queue.  I did not like that a rogue developer could steal my messages, but that would have to wait for AF v3 or beyond.

I have not had the need to override Actor Core in such a way that I needed the Receive Queue - I always called "Call Parent Method".  Actually, I only have one class that has an override to Actor Core and that is my UIActor class.  There it essentially calls whet might be referred to as "UIActor Core" that ideally would set up it's UI loop with all of the controls on the front panel if necessary.

[LVB]

niACS,

Can you expand on the reasoning for including the Receive Queue.lvclass?  What is meant by symmetry?

[KuGr]

I can't speak for niACS, but I think by symmetry he means 'the equivalent but opposite'.  Such as a "remove" function if you had an "add" function, but perhpas the "remove" function was never called anywhere in your application.  If it were left out, perhaps someone might want it.  As in this case, I expect that someone else might say, where is the Receive Queue class if it were not there - like me .  I actually do use the Receive Queue class.

-Kurt

[justACS]

KuGr, you beat me to it.  Thanks!

[AristosQueue (NI)]

We had the same distaste, Kurt. V3 of the AF -- which we hope will be out not too far in the future, based on feedback received at NI Week -- will remove the exposure of the raw queue to the children.