Why can't a reentrant dynamic dispatch method preallocate clones?

[SteveChandler]

Does anybody know why a reentrant dynamic dispatch method cannot preallocate clones? The VI breaks unless you set shared clones.

[JÞB]

The limit makes recursion impossible for dynamic dispatch vi's  (can you imagine a large number of sibling methods called with deep recursion? Ouch my memory hurts!)

[nathand · Accepted solution]

A bit more information here: http://lavag.org/topic/10539-reentrant-vi-with-dynamic-input-terminal-must-use-share-clones-between-...

[SteveChandler]

Thanks - I even looked on Lava and didn't find it!

[JÞB]

---

@nathand wrote:

A bit more information here: http://lavag.org/topic/10539-reentrant-vi-with-dynamic-input-terminal-must-use-share-clones-between-...

---

I have to admit.  Steve Mercer explained it to me at a LUG (OK to the LUG) I'm still betting that this will eventaully be worked around by LabVIEW R&D.  When the use cases make the investment worthwhile

[nathand]

I might be missing something, but it seems to me this would be difficult.  With dynamic dispatch, you don't know which VI will be called at run-time, so you can't specifically pre-allocate a copy of a VI for that call.  Instead, LabVIEW would need to pre-allocate a copy of every VI that could possibly be called, and it would need to do this any time a class is loaded at run-time as well.  That's potentially a lot of copies of VIs allocated "just in case."

[SteveChandler]

I couldn't see any technical reason it would be impossible to allow preallocated colones for dynamic dispatched methods. I do understand how it would be impractical or difficult to implement. But then reentrancy was extremely difficult anyway. I think it took a year or two to get it working and resulted in a complete overhaul of the low level parts of LabVIEW.