Stateless VIs

[LAVA 1.0 Content]

I've been discussing this feature already earlier in some other thread but perhaps I raise this up also here...

What I'd really like to see in LabVIEW are stateless VIs. I don't mean that all VIs need to be stateless but there should be a new kind of execution option "Stateless VI". With stateless VIs I mean that the VIs would have absolutely no state. At runtime they would of course have dataspace, but once call has exited, the dataspace would be cleared. This meands that these VIs would have no uninitialized shift registers, no front panel components would contain any values, there would be no local variables, all front panel components would need to be connected to connector pane inputs would need to be connected (outputs can be disposed at call exit).

Why all these limitations? Well, first of all if VI would be stateless, it could call itself recursively, so real recursion without open VI reference would be allowed resulting in much faster and easier recursion. Second stateless VIs wouldn't have persistent dataspace meaning that the same VI could easily have as many instances as required for effiecient runtime performance. There would never be waiting for the VI to become free from another call, it would always be free and ready to run. There would be no need to find out if the VI is free but the VI could just be run the VI. The compiler didn't even have to keep the VI as a separate module but it could build much more efficient code by optimizing over VI barriers.

All this and probably even much more that I cannot think of results in much higher performance, dataflow in it's purest sence. Even besvingen would probably be satisfied with the new increased performance. This would also bring LabVIEW more closer to functional programming language, which is very powerful programming paradigm.

[Mike Ashe]

How would you suggest implementing the recursive function? Using the existing Call VI node or a new type of primitive, specifically for recursive calling of oneself?

[crelf]

What I'd really like to see in LabVIEW are stateless VIs.

I agree that a stateless VI could be a really powerful addition, but I'm at a loss to understand how one could call itself recursively without the dynamic call - when it's running it has a dataspace, so how can it go into stateless state and then get its dataspace back when the next level down has completed?

[Mike Ashe]

Got to have some type of local stack, but that starts to get a little away from the stateless. I think what is needed is something that does not store data or state between successive calls at the same level of call hierarchy, but drilling down and answering up is okay as long as once the call is done everything gets flushed.

[LAVA 1.0 Content]

How would you suggest implementing the recursive function? Using the existing Call VI node or a new type of primitive, specifically for recursive calling of oneself?

Well, you just need to initialize a new dataspace for each call and flush it when call exits. So each call would have a separate dataspace. At least other programming languages perform in this task much better than LabVIEW with open VI reference.

[crelf]

Well, you just need to initialize a new dataspace for each call and flush it when call exits. So each call would have a separate dataspace. At least other programming languages perform in this task much better than LabVIEW with open VI reference.

I'm failing to see the difference then - what's the point of having the new VI type if it's going to have a dataspace? Surely the improvement wouldn't be that much...(?)

[LAVA 1.0 Content]

I'm failing to see the difference then - what's the point of having the new VI type if it's going to have a dataspace? Surely the improvement wouldn't be that much...(?)

First, you could just drop it to the block diagram of itself, no need to open VI reference. Second VI reference is currently opened somehow inefectively using path as a key; stateless VI code would be in memory already in compile time and only the dataspace needs to be duplicated. It's not different from duplicating a buffer at wire branch. Third stateless VI dataspace cannot be accessed from outside the current instance of the VI. This makes it possible for the compiler to compile more effective code since it doesn't need to allow the VI to be accessed asynchronously by other concurrent threads. So single instance of stateless VI can in principle ran as effectively as a single threaded program - there is no need for synchronizing the data between the threads or even leaving doors open for that.

[crelf]

First, you could just drop it to the block diagram of itself, no need to open VI reference.

Can't you just use the "Call Setup > Reload on Each Call" for that?

Second VI reference is currently opened somehow inefectively using path as a key; stateless VI code would be in memory already in compile time and only the dataspace needs to be duplicated. It's not different from duplicating a buffer at wire branch.

I agree on this one, and as I said in my previous post, I don't think this would be difficult for the NI team to do (although I'm not an NI R&D team member and I haven't seen the code behind LabVIEW )

Third stateless VI dataspace cannot be accessed from outside the current instance of the VI.

Again, can't this be acheived using "Call Setup > Reload on Each Call"?