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

[drjdpowell]

Kegghead beat me too it.  Exactly what I was going to ask.  Well, except I understand why not to use "not a refnum", but what is wrong with just using the "first call" primitive to open the reference once?

[AristosQueue (NI)]

http://lavag.org/topic/15546-are-you-misusing-the-not-a-refnum-function-and-putting-your-app-at-risk...

(More of a reply to powell's question in a moment...)

[AristosQueue (NI)]

> but what is wrong with just using the "first call" primitive to open the reference once?

It's called paranoia for a reason. Long and short of it, I don't really understand the rules under which the First Call primitive gets reset, and those rules don't seem to be exactly the same as the rules for when a reference gets thrown away (a rules set that I understand thoroughly). I've never studied the actual code of the First Call prim, and there's user comments and documentation in various places that, without really pounding on it, make me skittish.

I use that primitive all the time in my own apps, where I know all the calling conditions that a VI will be used in, but this is a library VI that will be used in all sorts of user apps, which means every exotic condition you can imagine -- static VI references, VI Server, remote calls, calls into DLLs, etc. I didn't like it.

[kegghead]

Yeah, I'm aware of the "misuse" of Not A Refnum primitive. When I said "check for Not A Refnum" i meant check versus the constant, not use of the Not A Refnum? primitive, but I see room for ambiguity in my statement.

Checking for a Not A Refnum constant in your case though shouldn't be a race condition since the refnum is never exposed outside the scope of the VI.

[AristosQueue (NI)]

> Checking for a Not A Refnum constant in your case though shouldn't be a race condition since the refnum is never exposed outside the scope of the VI.

Right, but that's a performance hit... just calling the Async Call By Ref is equivalent to calling Not A Refnum... and then doing the work. Since the majority of calls will already have the ref allocated, there's no need to check validity twice.

[kegghead]

Hah, well yes, but you're way isn't without performance costs either. You check for a non-zero iteration, perform an AND operation on the status of the error cluster, and need to check your loop break condition. That actually seems like more performance overhead than a single equality check for the refnum against a type-specific for Not A Refnum constant.

All in though, I'd be surprised if any of it makes much difference given everything else that's going on when launching an actor.

[AristosQueue (NI)]

Not A Refnum requires a swap to the UI Thread and acquisition of a mutex in order to check whether the refnum is still valid or not.

(Not sure why I typed that first part... it's late on a Friday is my only excuse.)

[kegghead]

No no no, I was thinking something like this:

(Please ignore the missing error wire.)

But I think I see now what you were trying to avoid. This code depends on the lifetime of the feedback node value, which might not be the same as the lifetime of the refnum. Hence you wanted to use the actual validity check.

[AristosQueue (NI)]

kegghead wrote:

Hence you wanted to use the actual validity check.

Bingo.

[drjdpowell]

AristosQueue wrote:

> but what is wrong with just using the "first call" primitive to open the reference once?

It's called paranoia for a reason. Long and short of it, I don't really understand the rules under which the First Call primitive gets reset, and those rules don't seem to be exactly the same as the rules for when a reference gets thrown away (a rules set that I understand thoroughly). I've never studied the actual code of the First Call prim, and there's user comments and documentation in various places that, without really pounding on it, make me skittish.

I use that primitive all the time in my own apps, where I know all the calling conditions that a VI will be used in, but this is a library VI that will be used in all sorts of user apps, which means every exotic condition you can imagine -- static VI references, VI Server, remote calls, calls into DLLs, etc. I didn't like it.

FYI from several months later, you were right to be paranoid.  The VI ref lifetime is tied to the top-level VI that first launches an actor, and if that VI goes idle it is invalidated.  But if any actor is still running, then the First Call primative is not reset, so there is an error the next time an actor is launched.  Not something that normally happens, but I encountered it when I tried having a debug-display actor (my framework, not AF) keep running after the main program stopped.

-- James