Asynchrono​us Call By Reference Should Provide Another Way for Matching a Wait to the Start

[jcase]

The asynchronous Call By Reference feature allows you to start multiple asynchronous calls simultaneously using one reference. However, when doing this, it is not always possible for the Wait On Asynchronous Call node to know which call to Start Asynchronous Call it is handling. This is especially common when the Open VI Ref option 0x40 is used to enable simultaneous calls on reentrant VIs using one reference.

There are currently two ways to know at a Wait node who started the call:

1. Use a unique VI reference for each asynchronous call -- The problem with this approach opening and managing multiple references is more expensive than making multiple calls on one VI ref. (Note that the VI ref can be reused for another async call after a user has finished handling the Wait.)
2. Create a unique ID and pass it to and from the target VI. -- The problem with this approach is the target VIs interface needs to be updated to accept a unique ID and return the same unique ID.

Neither of these are ideal.

I propose the Start Async Call and Wait On Async Call nodes themselves return a unique call ID. This unique ID could be used to programmatically determine which call to Start and Wait match.

[AristosQueue (NI)]

Wouldn't that add bookkeeping on LabVIEW's part to every call, bookkeeping that would be extra overhead for use cases that don't need such a unique id? If I break an array into chunks, for example, and spin up multiple copies of my search VI to search each chunk, I don't need to know which instance I'm catching in the Wait -- the search results themselves have the index where the item was found. Having LabVIEW doing additional work would be unnecessary waste of memory and CPUs. Perhaps if you made it an optional feature to be enabled only if needed?

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.

[littlesphaeroid]

Well, I like this idea.