Reference used for async launching VIs taking 6 seconds to close?

[p27]

I was attempting to track down some strange closing behavior (currently just taking a long time- varying up to 6 seconds to close) of an app that launches N number of processes asynchronously.

After launching them things operate as expected. 

To close from the top level, the main (top) app messages them the stop instruction through a user event.

it turns out the top process's stop case that executes a reference close (after the async-launched VIs have already closed) seems to be taking a significant amount of time.

I'm launching with option 80 and 40, and the close ref takes 6 seconds even if I skip launching the VIs.  Reentrancy is preallocated.

here's the launch:

and the close (thats taking a long time) in the stop state:

It was suggested to me to try to implement the creation of it the same way it's done in AF so I might try that next to see if it changes anything....

[wiebe@CARYA]

Closing a dynamic VI can take much longer then starting. I've seen that too, with other Open VI Reference options (0x8, 0x0). Even simple complexity in the VI will dramatically increase closing time.

I guess you can start a dynamic VI to close the reference 😊.

[p27]

I forgot about this post actually... as I started cleanup of this particular app I found some user events (used for communicating between launcher/launchee processes) that were not being being destroyed and this seemed to immediately solve the problem- where the app would shutdown/close immediately.  However, shortly after without any "significant" (meaning no ref management changes) it seemed to come back, but since it doesnt seem to be a problem in the build I'm hoping it's nothing significant...

and yea... I could...

🤣  async-ception, launching to close launchees... but who's gonna close the closers???

[wiebe@CARYA]

I avoid call and forget and call and forget light the plague.

I never had good luck with them. My main problem is the VIs and classes are remain locked after I stop everything. A showstopper for me. And it used to crash a lot (for me) when they where new (not sure now).

Very often (always for me) I can use a normal Dynamic VI or Polymorphism. Dynamic VIs are really only needed when you don't know what modules are needed during runtime And even then sometimes polymorphism can be used. Dynamic VI calling is very often a quick fix that comes back to bite you... 

[p27]

By dynamic you mean dynamic dispatch?  

And no matter how much I try to verify the stop-chain will work I always seem to find new hiccups when I've launched N processes the deal with various subsystems that can take different lengths of time to close for various reasons...

I've found using call and forget to be very useful, but will admit if I'm not careful it can be a struggle to wrap things up for close from a top level perspective.

I've been using a template of my own for enough years that I'm due for an upgrade, perhaps something actor based that uses dynamic dispatch...

[wiebe@CARYA]

Either a normal Open VI Reference with option 0 or 8 (Dynamic) or Dynamic Dispatch.

It's a pain to use Open VI Reference and then having to set all inputs by their references. I'd prefer a call and forget or call and collect, if they worked for me. Having a connector pane is more convenient.

DD can be used in combination with a for loop setup to run with parallelism, An array of 10 tasks can be executed in parallel, and the for loop will simply stop when all tasks are done. 

[p27]

I ran into this issue again in another case and I think I may have figured it out (still testing but looking good).

I was using option 0x40 with preallocated clones instead of shared clones.

if you look at the help:

so I changed to shared and now it seems to be closing in less than 200ms everytime (usually 50)