Can those queue references as stored in a caller be 'dynamic'

[LuI]

Hi all,

I am just a beginner with AF, but have not yet found an answer for my problem. Have read a number of documents from here and the LV help and elsewhere, but no answer 😞   BTW, I am working with LV since v3.0, so I'm not feeling like a LabVIEW beginner 😉

I am designing a communication service that needs to connect to an unknown number (<~10)  of external devices, using sockets, RS232, USB, whatever. The connection is initiated by an operator or a kind of script.

I want to abstract the connection with a nested actor, being called by request to the main (caller) actor.

If I see what I get when creating a new AF-project in LV2013 v13.0.1.f2 (32 bit) is a 'class consisting of (amoung others) a 'DNL_Alpha Queue' and a 'DNL_Beta Queue'. These are queues that have been designed and created at devellopment time and are static AFAIK.

I would like to change this and replace the 'collection' of DNL-queues by an array of those queues, Think of an array of cluster of (Name as string, Queue-Ref as queue). That way I assume I could add a new queue for every nested actor that is loaded at runtiime. And I could address those queues by iterating the aray, searching for the correct name and retrieving the queue ref when found.

I am aware of the risks of non-unique queue names etc., but I believe this could be solved by a proper naming algorithm. An timing is not an issue here - the system shall run for long periods, has no requested throughput or reaction times.

Can this be done? And are there more problems I am not yet seing here?

Any help and comment is appreciated!

TIA

--

Uwe

[KuGr]

Uwe,

I am probably in a minority here as I do keep track of my launched actor queues in a list and it is indexed by a string (typically a name loaded at startup but could be a GUID).  In fact this list is a class I call MessageEnqueuerList.lvclass.  My Actor class (derived from AF Actor) actually holds three of these classes. The other two are for 1) observers and 2) other known queues. I have not had any issues with this approach and I have been working with AF since 2010.

You seem aware of the main risk of names and as long as you can handle the risks, IMO the approach will work.

I have not studied the AF based plug-in architecture in the LabVIEW Best Practices group, but it might use arrays of queues.  That might be something you can look at.  However, it may just launch a single actor at a time.

-Kurt

[LuI]

Thanx Kurt,

I'll give it a try.

Greetings from Germany!

--

Uwe

[AristosQueue (NI)]

I would advise against naming your queues even for this use case. Instead, just have your root actor store the array of refnums and a parallel array of names. That makes it possible to look up the names much faster (you don't have to get the name from the refnum, which requires thread synchronization with the Queue Status primitive) and it keeps out the temptation to look the queues up by name in other parts of your code where that's generally ill-advised.

[FabiolaDelaCueva]

What about storing the references in a Variant as a Look up table? would that be faster for the lookup?

[AristosQueue (NI)]

Yes, that would likely be faster. I am never sure when to mention the advanced options and when to stick with something simple like a paired array.

[KuGr]

I agree, it is not a good idea to name the native queue reference. In addition, it would require some modifications to the Actor Framework library which in my environment is not permitted.

I guess I wasn't too clear.  I essentially have a lookup table embedded in my MessageEnqueuerList.  The MessageEnqueuerList instances are not a global lists.  Each launching actor has its own copy of its nested actors.  The launching actor assigns the name used for the lookup table.

The "under-the-sheets" implementation of the lookup table my MessageEnqueuerList is actually a variant and I use the variant attribute structure.  The variant is wrapped in a ObjectByNameCollection class. Searching in this case is pretty quick.

Hi Fab!  I am no comp-sci guy but that is what I have read also about the variant attribute structure.  There is probably some minimum number required.  I also don't know the 'cost' of the Variant To Data node after you extract the data from the variant attribute collection.

[FabiolaDelaCueva]

Hi Kurt,

For the most part I am just a lurker in this forum. I thougth that was probably how you were implementing it, I was just curious and wanted to learn more about how the queue manager was handled.

Thanks,

Fab

[LuI]

Agree Steven. And I was not planning to use an array of _named_ queues, but an array of clusters of (name, queue).

And another agreement - using a lookup table is probably better and faster,

Again, this project is not requiring high speed, but more flexibility in the number of started actors. And that is a way to achieve this flexibility. The only problem is to use a unique and consistent naming..

What about integrating this into the AF?

Greetings from Germany!

--

Uwe

[AristosQueue (NI)]

LuI wrote:

What about integrating this into the AF?

The "look up by name" is functionality that is not general enough for most actors, but we have added some managment of nested actors into the AF for LV 2014. You can download the experimental branch for LV 2013 from elsewhere on this community forum if you want to see the changes that will ship later this summer.

Creating one parent class "Lookup Table Actor" that has this functionality might be a useful addition to vi.lib, but I wouldn't put it in the Actor Framework.lvlib itself. Worth debating among the community.