Allow Dynamically Dispatched Methods to be called Asynchronously

[PrimaryKey]

Hello,

the current functionality doesnt allow to asynchronously call a method that has any dynamically dispatched inputs. This causes a need to create a statically dispatched wrapper around the dynamic method which then can be called.

This is a source of frustration for me because it forces you to have code that is less readable, and this doesn't seem to be any reason for having functionality like that. Since you allready need to have a class loaded in the memory to provide it as an input for the asynchronously called VI why not just allow to use dynamic dispatch there (the dynamic method is allready in the memory).

How it is right now:

Solution: Allow to make asynchronous calls on methods with dynamic dispatch inputs.

[AristosQueue (NI)]

This is a good idea... kind of. I'm going to lay out the details of the problems with this idea. This is NOT a rejection of the idea, but rather an invitation for folks to comment on how those problems could be worked around elegantly.

This is a discussion that comes up from time to time. The problem with this idea is that a VI Reference refers to a specific VI. Here's the general scenario... someone has a VI reference to the parent class VI. They wire it to Asynch Call By Ref. But then they want to do something ... like abort the running VI or open the front panel or harvest a value from a control. But the VI refnum they have in their hands is not the same as the VI that actually started running. What that implies is that the Asynch Call By Ref -- and the Call By Ref for that matter -- would need to return a different VI refnum than was originally passed into them. That has ramifications for performance since allocating a new refnum requires the UI thread, which would be an invisible dependency and potentially quite expensive on every ACBR or CBR call. It also means that users would have to get used to closing a reference after *every* ACBR or CBR call or face a memory leak. It gets weirder -- the reference returned from the call would itself be a VI refnum with a dynamic dispatch conpane, so if you wired it into a second ACBR, you'd get *another* separate VI refnum. There's no type difference between a VI refnum before the call and a VI refnum after the call.

You can say, "Well, if we just return the same refnum that was passed in, that keeps the bookkeeping down and it would solve many problems... the problem of talking to the actual VI that started running could be left as an open issue." But I observe that the need to communicate with that running VI is actually quite common... there's a need to stop that other VI when the system hits an unexpected condition, which is usually achieved by closing the VI reference. Without solving this, most apps that I observe would be left coding a lot more infastructure than just an extra wrapper VI.

After a lot of back and forth, the wrapper idea was the best one for keeping the reference complexity to a minimum. It made it clear which VI was executing in all cases. Most other solutions required some sort of new "method refnum" which was implicitly a reference to *all* the VIs that override the same method, and closing that one method refnum would close all the VI refnums. That really seemed complicated to explain and complicated to use.

So that's where we stand. What sort of designs would you propose to help with this?

[fabric]

Personally I'd be happy enough if the reference returned by the ACBR was simply the original reference to the parent class VI. Sure, being able to easily get at the reference of the runtime child would be nice at times, but I could do without it if that were the simplest way to make the proposed dynamic dispatch functionality possible. 

Not allowing me to do "A" just because that would make it hard to let me do "B" as well is not a great reason for preventing "A"! 🙂

[AristosQueue (NI)]

> Not allowing me to do "A" just because that would make

> it hard to let me do "B" as well is not a great reason for preventing "A"! 🙂

Ah, but this isn't a case of not allowing. I can't just get out of the way and suddenly this will work. This is a case of not enabling. And that change of words means we're talking about whether or not it is worth our effort to enable you to do A. And if A is very rare, especially in comparison to B, then us spending time enabling you to do A is a waste of time because few people will be able to use it. And if we aren't sure whether the solution to solving A would ultimately get in the way of ever solving B, then it makes more sense to leave the space open until someone proposes a solution for B.

And that's the situation with dyn dispatch for (A)CBR. It isn't trivial to enable the obvious solution and the complex solution isn't obvious.