Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Should Time-Delayed Send Message be Reentrant?

Solved!
Go to solution

This is a curiosity thing as opposed to an actual issue (possibly a bug report as it's leaking more references than needed)

 

I noticed the execution setting of Time-Delayed Send Message is reentrant (shared clone), which is normal for a toolkit. However, a shift register is being used to hold on to the reference of the daemon process (like an FGV), with the intention that a new reference doesn't need to be created every time. - but FGVs don't play nicely with reentrant functions.

 

The shift register will keep the reference in the shift register when the same instance is being used (i.e. same VI on the calling BD). But new references are created when different clones are used (running two in parallel).

 

With the current execution setting, several references of 'Time-Delayed Send Message Core.vi' are being leaked instead of just the one.

 

Launch Actor Core.vi is using exactly the same design pattern, except it is non-reentrant (so the SR always acts as an FGV). Meaning only one reference of Actor.vi is leaked.

 

Thoughts?

0 Kudos
Message 1 of 5
(591 Views)

If I understand shared clones correctly, this will leak one reference for every clone in the pool.   Given that the duration of the vi is short and there typically aren't a large volume of calls to this vi, I would expect few clones to be created for the clone pool.  So, maybe there are 3-10 leaks (just guessing) rather than just 1 leak.   

 

  • Shared clone reentrant execution—LabVIEW allocates a pool of clones, initially populated with one clone, to share amongst callers. When a caller calls a shared clone VI, it pulls a clone from the pool and returns the clone when the call finishes executing. If the pool is empty when a caller calls a shared clone VI, LabVIEW creates a new clone for that call and places the clone in the pool when execution finishes, thereby expanding the clone pool.
0 Kudos
Message 2 of 5
(577 Views)

That's my understanding too - so not a big issue, I'm just curious.

 

In some of my applications, I might use the function in quite a few different places (maybe up to ~30 or so), just because it's a useful tool to keep an LED on for x-ms, or have actors read volatile data periodically.

 

I've not had any issues, I just stumped across the execution settings and thought "that doesn't look right"

0 Kudos
Message 3 of 5
(572 Views)
Solution
Accepted by topic author McQuillan

Even if the calls to this VI are heavy, the time spent in this VI is very brief -- it hands off to an asynch call by ref quickly, so to build up lots of clones, you don't just need many calls to it, you need many simultaneous calls to it. The single VI reference is sufficient to spawn multiple asynch call by ref calls.

 

Honestly, it probably should be non-reentrant, but there was someone complaining about a VI Analyzer test or something that looked for all subVIs of a reentrant VI to be reentrant. I don't recall exactly, but I remember turning it on temporarily for that check and I guess I never turned it back off... never showed up as a problem in any of the profiling later.

Message 4 of 5
(510 Views)

Is this one of the cases where opening a new VI reference will block if the UI thread is busy? That would be a reason to leave it non-reentrant so you only ever have to open one reference per app instance.

0 Kudos
Message 5 of 5
(460 Views)