Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Suggestion: open a ref to Actor.vi only on first call

Currently, each launch of an actor causes a strictly-typed reference to "Actor.vi" to be opened, using options 0x80 (Fire and forget) and 0x40 (simultaneous calls), and later closed again.

I suggest instead only opening the reference once, on first call, and reusing it, for the following reasons:

1) I think this is how 0x40 is meant to be used (multiple uses of the same reference) and I'm not sure the current use is correct.

more importantly...

2) Open VI ref requires "root loop", and can be blocked by issues such as the User opening a pull-down menu.  This could be a major problem in an application that needs to create actors on demand, rather than just at the start of the program.  Keeping a single active reference avoids this problem (except, of course, for the initial actor launched).

-- James


0 Kudos
Message 1 of 38
(19,449 Views)

Multiple calls to the same reference only works as long as you're not using the front panel at all. Each actor needs an independent front panel.

[Note: This is how I understand it from the docs and talking to devs. I have not tried the approach you propose because of this restriction, which might not actually exist if I've misunderstood something.]

0 Kudos
Message 2 of 38
(5,314 Views)

Why does "Actor.vi" need its front panel?  It's just a launch shell for calling "Actor Core.vi".  I first saw a single ref used this way in mje's "MessagePump" package, and I just modified my own design to use this method without problem. 

BTW,  I just tried opening the front panels to the multiple clones called this way and they seem to work fine.

Re (1), when I last tried out the Actor Framework (2012beta1, see my post in the beta forum) it seemed to be creating many more copies of "Actor.vi" than needed.  My theory is that each new reference with 0x40 creates a new pool of clones just for that reference, which are held in memory while any clone is still running.  So, if nothing else, I would suggest dropping 0x40.   However, issue (2) is more serious, as it is leaves open a rare but potentially critical failure mode for any software built with it ("Launch Emergency Shutdown Actor",...tick...tick...tick).

-- James

Here's the relevant code from "MessagePump", for any lurkers who are interested:

GetStartAsyncRefnum.png

0 Kudos
Message 3 of 38
(5,314 Views)

Good point about Actor.vi... I often forget that I've divided Actor.vi from Actor Core.vi. Given that, and the rest of your post, this does seem like I should investigate it further. I seriously doubt I can make any further changes in the LV 2012 setup, but I'll see about revising it for the future.

I'll let you know what I find.

0 Kudos
Message 4 of 38
(5,314 Views)

Indeed, the main reason for the GetStartAsynchRefnum.vi in the MessagePump is so that the root loop is only necessary once (kegghead@ni = mje@lavag by the way). Obviously I use the framework quite a bit, I tend to initialize that particular global very early in the application lifetime, long before I've actually started spinning off asynchronous tasks and generated any kind of UI.

drjdpowell wrote:

Re (1), when I last tried out the Actor Framework (2012beta1, see my post in the beta forum) it seemed to be creating many more copies of "Actor.vi" than needed.  My theory is that each new reference with 0x40 creates a new pool of clones just for that reference, which are held in memory while any clone is still running.

I've seen this behavior too though not characterized it too much. From the experimenting I've done, opening the first refnum obviously instantiates a clone, then each start spawns a new clone as necessary. The original clone used for the open operation never seems to get used. So if you're opening up a refnum each time you need to spin off a new clone, you're actually getting two clones for each call. That's anothe reason for using the LV2, though it is a very minor one since the dataspace for the VI is pretty trivial.

0 Kudos
Message 5 of 38
(5,314 Views)

kegghead wrote:

From the experimenting I've done, opening the first refnum obviously instantiates a clone, then each start spawns a new clone as necessary. The original clone used for the open operation never seems to get used. So if you're opening up a refnum each time you need to spin off a new clone, you're actually getting two clones for each call. That's anothe reason for using the LV2, though it is a very minor one since the dataspace for the VI is pretty trivial.

I was getting 5 clones per opened reference with 0x40.  I believe there is supposed to by one clone per core (I have a 4-core machine), so I was confused by the fifth one.  Perhaps it serves as some sort of "master" copy to which the reference points.

AQ, it's actually quite a small change, five minutes work, but then you would probably have to test it.  Could easily wait till 2012.1.  Most people are probably doing projects were all actors spin up on startup, so the root loop issue isn't important.   But eventually there'll be projects that continually create temporary actors for small tasks.

0 Kudos
Message 6 of 38
(5,314 Views)

kegghead wrote:

though it is a very minor one since the dataspace for the VI is pretty trivial.

Till one reads up on other actor-focused languages, like Akka, where the overhead is 300 bytes per actor(!) and they can talk of systems using many thousands of actors.   "Actor.vi" is code+data=10k in size.

0 Kudos
Message 7 of 38
(5,314 Views)

When do I close this reference? Do I have to keep a count of actors and release the reference when the last actor quits? Or are you proposing I just leave the reference open and let LV's "close on idle" handle it? That's something I'm loathe to do -- it works, but I really prefer to make the close explicit.

0 Kudos
Message 8 of 38
(5,314 Views)

From the ACBR node developer:

1) Open VI Reference only requires root loop if you wire in a path [EDIT or if you wire in a strict connector pane]. Name requires UI thread but not root loop. So it can run while a [pop up/drop down] menu is open.

2) What I actually want is 0x80, which allows me to open the reference and close it, but will not create the "1 clone per core" that we have today, which is wasteful. Don't want to leak the reference if I can avoid it, if only because that will show up as a leak in the Desktop Trace Toolkit which many people use to debug the Actor Framework.

May post more later.

Section in square brackets was edited by AristosQueue to reflect information learned later.

0 Kudos
Message 9 of 38
(5,314 Views)

That's VERY good to know, thanks AQ.

I don't like leaking the refnum either, but I chalked it up to a comprimise for having more dependable process spawning. I wasn't aware opening by name was handled differently, I'll consider that should I get around to revising my own framework.

I do not like the one clone per core solution either, and would be eager to find a work around.

0 Kudos
Message 10 of 38
(5,314 Views)